The reason coloured cubes behave this way is because of how you treat collision check - it's not a bug, it's about setting up collision checking system.
Predicting collisions vs computing actual collisions
Imagine a cube with
speed equal to 1; it will move one pixel forward each room step, until collision with a black cube occurs.
Since you moved the cube pixel by pixel onto collision, it will snap with the black cube one step before the actual collision occurs.
Let's say step tn is the time (in room steps) the moving cube snaps with the black one, without actually colliding with it; this is represented in the above image. Then the next step, we call tn+1, is the very moment the moving cube is overlapping with the black cube even if for a single pixel.
The highlighted area (intentionally exaggerated) is the result of overlapping sprites when collision is detected, but there are no countermeasures for correcting coordinates.
When you predict a collision (e.g.
place_meeting(objID,x+a,y+b), where arguments are current coordinates plus speed values), you want to know if the next position implies overlapping (not snapping) of objects sprites.
On the other hand, computing a collision on the current coordinates (e.g.
place_meeting(objID,x,y)) you are asking the engine if the object is hitting a given object already: so the collision as we mean it has already happened. Before going on with game logic, you should carry the object away from the other one so that it doesn't seem it kept moving forward before collision actions occurred.
If the cube moves faster, there may not be a moment when the moving cube snaps the fixed cube; it is a bunch of pixels in front of the still cube, and the next step it is overlapping the other, or even be moved beyond if travelling at very high speed!
Try to check for collision before moving the cube; if a collision is detected at next position, before changing the cube direction, use
move_contact_solid() to snap the moving cube to the fixed one, right before the actual collision occurs. Then, apply the speed direction variation to turn the cube around.
Remember: such solutions are always independent from
room_speed or other time variables, it's only on the order actions are performed in your game logic.