Well, as explanatory your post is for others might using Scanner class, for me it's still a class I wont use it in my codes.
Also, sorry for bein on the direct way again, wich I know you don't much like on me, you may didn't read my post carefully enough. I explicit mentioned the issue an os-console (and for, this is not limited to windows' cmd.exe but also to standard bash-shell on linux) processes input reads different than most beginners thinik it would. That's it - if you hang in any sort of System.in.read() by any way, it won't return until the console passes the data input by the user is piped to it. And this only happens the very moment you hit return on the console wich triggers a stream of "<what ever the user input>" + os-console line delimiter (on windows \r\n, on unix \n, on mac it was just \r - but I think that changed). So how ever how much data is read through wich class, it can only be something between "<nothing at all>" and "<what ever user input>" plus always the line delimiter.
What most beginners falsely think Scanner would do: When they print a numbered menu and want the get the users choise the call nextInt() to get the entered number.
How Scanner class actually works: As the console not only delievered the entered number but also the line delimiter - the nextInt() only processes the integer but would leave the delimiter still lying in the buffer waiting to be processed by any suiteable method like simple next() or nextLine().
And exactly that's what's the main issue in the code of OP: mis-using of Scanner class by most likely lack of knowledge how it really works. I didn't bothered to work through the whole code - but lets look at only the first choice:
- the menu is printed
- nextInt() tries to process the next available integer - as the buffer is empty at that point when run for the first time it somehow gets down to System.in.read() wich blocks and wait for input from console
- the user inputs some number and to "submit" it to the nextInt() RETURN has to be triggered
-- now what's really happens is, that the terminal sends the entered number PLUS the line delimiter
-- nextInt() now processes the available integer, returns it, and the line delimiter is left alone in the buffer waiting to be processed
- switch triggers listUser(), breaks, and loop wraps around
- now nextInt() is hit again - but as there still some data left in the buffer - they get processed first - wich is the line delimiter - wich obvious can't be parsed into an integer - wich, according the doc, should throw an InputMismatchException - IDK, IDC, but I guess as OP didn't mentioned it, I guess line delimiter just gets discarded silently and further processing starts from top of the list
A possible better approach could had been: constantly using Scanner.nextLine() and add Integer.parseInt() (or what ever input is expected). This way, it is ensured that the full line piped by the console gets consumed, including the line delimiter, nothing is left in the buffer, and with correct exception handling it can be ensured it's inputted what is requires. In this very case - it even doesn't matter if using Scanner(System.in).nextLine() or BufferedReader(InputStreamReader(System.in)).readLine() - wich I guess is done by Scanner internally, or some similar.
Anyway - it's not gettin us futher fighting about personal opinions about Scanner class - the forum is to help the ones asking for it - so let's get back to it:
The OP asked why some inputs are "eaten" and has to be entered twice - the solution: wrong usage of Scanner nextXXX() methods wich needs to be corrected or can be done in another way.
I just added my personal comment about this kind of "mistake" happens to many beginners as they simply mis-understand how Scanner really works internally and mostly miss the point, that the nextXXX() methods may not work as the think they should but leavy something in a buffer wich gets processed the nxt time one of the nextXXX() methods gets called. Also I mentioned, for me the DataInputStream class fits way better for reading binary formats or data I've written out by DataOutputStream on a Socket connection.
Could the code improved by just replacing all of the Scanner with another input method? Maybe. Could or Would the solve OPs issue? Possible. Does it make sense in anyway of learning and letting OP the chance to discover his own way of console input? no way at all.
Allthough it all gets down to somewhat like System.in.read() - there so many possibilities built into SE API - anyone should get the chance to get used to what one likes best - we can only help on errors and mistakes to get the chosen way right.