Marlin possible bug? Enable endstops prematurely

I am using a Printrbot Metal Simple with their firmware which I understand is based on Marlin, and I came across the sequence of G-code commands below which produces unexpected (to me) movement. Specifically it appears as if it should move in a square four times, but instead it wanders off.

I modified the firmware to add massive debug printout, and traced it down to the G28 command which enables endstops. Since the movement is very near the bed, the inductive z-probe is triggered and the z endstop is enabled while there are still movements in the queue. The autoleveling of the bed creates small z movements from the pure X and Y commands, and the z components and enabled endstop makes it discard some of the commands.

I think this is a very minor bug, which most people will never see.

G21           ; set units to millimeters
G90           ; use absolute coordinates
G28 X0 Y0 Z0  ; home x, y, and z
G29           ; Probe for level
G1 X75 Y75 Z10; Get ready
G1 Z0.25      ; Descend
G1 X80
G1 Y80
G1 X75
G1 Y75
G1 X80
G1 Y80
G1 X75
G1 Y75
G1 X80
G1 Y80
G1 X75
G1 Y75
G1 X80
G1 Y80
G1 X75
G1 Y75
G1 Z5
G28 X0        ; home x
M84           ; motors off

The unused enstops can trigger randomly if they are not properly configured.

The unused endstops should always have the pullup resistors enabled and the endstop inverting set to true. This will insure that the unused endstops will always be open. This applies to all control boards that use the Mega2560 chip. Example:

My printer uses the XMAX, YMAX, and ZMIN endstops. The unused endstops did not have the pullups enabled and the inverting was set to false.

The configuration should be:
#ifdef ENDSTOPPULLUPS
#define ENDSTOPPULLUP_XMAX
#define ENDSTOPPULLUP_YMAX
#define ENDSTOPPULLUP_ZMAX
#define ENDSTOPPULLUP_XMIN
#define ENDSTOPPULLUP_YMIN
#define ENDSTOPPULLUP_ZMIN
#endif

// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. (Not used)
const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. (Not used)
const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. (Mechanical NC switch)
const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. (Mechanical NC switch)
const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. (Mechanical NC switch)
const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. (Not used)

This is not a problem of unused endstops triggering randomly. This is the existing endstops triggering as designed, and the software not ignoring it when not homing. To be precise, it thinks it is homing because it has received a homing command, but there are still movements in the queue that need to complete before the homing command is executed. THOSE commands in the queue are processed with endstops enabled, when they shouldn't.

I've opened a Marlin bug, we'll see where that goes.