When you write I don't run my machine in the negative machine space on X and Y axes, do you mean that you have compiled GRBL with with HOMING_FORCE_SET_ORIGIN?
https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/config.h#L129

This has been a long time issue where the bounding box ends up in the wrong quadrant and was introduced when I "fixed" this for a user running with "HOMING_FORCE_SET_ORIGIN". So for everyone running the default settings (using negative space) the bounding box ends up in the wrong quadrant.

I have compiled GRBL with HOMING_FORCE_SET_ORIGIN defined. My homing direction mask is 3 (x homes in the negative direction, y homes in the negative direction, and z homes in the positive direction). So, with regard to machine coordinates, I operate in the positive space for X and Y, and in the negative space for Z. The only way for the visualizer to automatically know this would be to get the homing invert mask from the grbl firmware settings, but I think there's probably more to it than that - I had forgotten about HOMING_FORCE_SET_ORIGIN. I'm not sure if this is something you can do completely automatically or not...

OK, now I just feel stupid.

GRBL does seem to report this:
https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/report.c#L391

So we could add a new capability here (like MACHINE_COORDINATES_IN_POSITIVE_SPACE):
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/CapabilitiesConstants.java

When this is available we'll invert the bounding box like you suggested. In other words reverting this:
#2285