if(Serial) not working correctly on micro or pro micro
1) have i got an out of date bootloader?


No. This has nothing to do with the bootloader.


  2) if so how do i check?


See above.


  3) is this intended behavior and if so why?


In a manner of speaking, yes - see below.


  4) is this a bug in the arduino bootloader or libraries?


No. Elsewhere.  See below.


  5) short of having to change my code to look for serial data to start and stop the debug mode (serial comms are being used for other things in the background) is there any way i can work around this? reading from hidden registers etc?


Yes, you can, but only once you understand exactly what is going on.

The problem with USB serial (AKA CDC/ACM) communication is that there is no way of knowing if the port has been opened by the computer or not.  That functionality was just never designed into the protocol.

However, there are two virtual modem signals that the computer can assert that the CDC/ACM device at the other end can examine - one is the equivalent of DTR and the other the equivalent of RTS.

The Arduino's CDC/ACM code examines those, and if either are asserted then it assumes the CDC/ACM port is open. If neither are asserted then it assumes the port is closed.

Now comes the tricky part:  You have little or no control over when those signals are asserted or not.  There are three separate factors that decide what happens:


The software being run can manually control the signals.  The Arduino IDE does this to ensure boards that use DTR to reset (like the Uno, etc) actually do reset.
The drivers on the computer can decide to automatically control the signals when the port is opened or closed
The operating system itself can control the signals when the port is opened or closed.


Some software will control the RTS/DTR signals properly, some won't. Some drivers will control the signals for you, some won't. Some operating systems (such as Linux) will, unless otherwise instructed, default to automatically controlling the modem lines properly. Others, like Windows, won't.

So the only way you can be sure that these signals are being controlled properly is to manually control them from your own software used for debugging, or to find a specific terminal emulator that controls the lines properly.