Thanks for the email with the files. It was my fault previously for not explaining properly. Nice code!

I see the problem. This is to do with the way the injected debugger has to work. We inject serial statements into the temp copy of the code, at the END of the line of code. Normally you might expect a debugger to stop or report at the start of a line but with code injection it is easier to report at the end of the line.

In doing this we have to workout how to add a serial.print() to the end of the line of code you have added a breakpoint to. As you can imagine some code lines are easier to workout an "end point" than others. In the case of one line if statements, for example, visual micro attempts to change the code line into a multi-line if statement so that it can then insert the special breakpoint serial messages.

Yhe debugger overviews do try to make the point about adding breakpoints to as simple as possible lines of code. It's not a perfect science and we always look to improve the system based on real world experience.

Your example shows that you placed a breakpoint on a switch statement and I guess it now makes sense to you that this would be a problem. It's a tough place to inject a breakpoint notification message. Your final code actually looked a bit like the following example, after the debugger had done its stuff. 

Notice the serial.print is in an invalid location, I am surprised the compiler didn't pick this up. Oops!

if(SystemState == STATE_IDLE) {
switch(MotorState) { Serial.print("Breakpoint here!! Ooops!");
case MOTOR_IDLE: 

Actually if you had inserted the breapoint the line before I think it would work okay. The breakpoint would only be hit when system state is idle and a "When Hit" condition of "Motor idle = {MOTOR_IDLE}" should show the current Idle state.

Does this make sense. It's a weakness of injected debugging and something we will improve gradually over time. I notice your code is very neat and makes a lot of use of nested single line statements. These will present a problem and will require some thought by you. Visual Micro can't currently make good judgement about where complex single line nested statements start and end so best to keep away from them.

Normally to debug Arduino, Serial.print statements are manually added to the code and must be removed at some later stage. This debugger does prevent the need to hack the code in that way but it might be that you still need to alter a few one liners to be enclosed in braces { } when diagnosing code issues.

Your code is so neat I am not surprised you have had so many problems. I guess the biggest point I can make is to be clear that we inject to the end of a line of code and it is not an exact science when faced with anything other than simple and clear bracketing {}. 

Sometimes it is also useful to note that because we inject you can place a breakpoint on blank/empty lines of code but please keep in mind how a new line of code will affect program flow {}.

Whilst not a perfect solution I hope this helps remove some frustration an thanks for your patience

Yes it's solid as a rock on simpler code.

Thanks again