Hello, I've seen your implementation and its different from how real world CNC works.
Maybe you already know how they work and continuing is useless.

The first bigger difference is that internally they work everytime with native system positions...

internally they work everytime with native system positions

Correct me if I'm missing the meaning….

Internally to Marlin, the current_position is relative to the coordinate space, as offset using G92, and you must subtract workspace_offset to get machine coordinates. Most of the time there is no offset, and 0,0 in the logical space corresponds to 0,0 in the machine space.

On Cartesian robots the Planner.position and stepper step counts in Marlin have always been in terms of the "logical" space — I presume so that there's a direct back-conversion from steps to mm. (For Delta and SCARA the planner/stepper positions relate to the machine coordinate space after kinematic conversion.)

I've been wanting to alter Planner and Stepper so that workspace offsets are stripped before going to the planner on Cartesians, but it's a middle-sized job. The macros RAW_POSITION, etc., were added as an interim step to standardize the conversion from logical (work-) space to machine coordinates, and with the NO_WORKSPACE_OFFSETS option these become no-ops.

So, are you saying that when we set the workspace to be at X100 Y100 in the machine space, we must still use G1 X100 Y100 to go to its origin?

Item 1

Well I'll try to explain but be patient, English is not my language and is not so easy to understand and to explain.
Let's start from the beginning.
When you set limits you use machine space positions, usually home position is 0,0.
Let's assume 0,0 as home position and 300,300 as maximum position, these are the the so called "software limits" while "hardware limits" are the endstop switches.
User can always move machine inside these limits.
User can define the so called "origins" that can be recalled by G5x opcode.
Let's assume that we have an origin in X100 Y100. When you set this origin "displayed" position is 0,0 and also all gcode positions are related to that, e.g. if you execute g0 x100 y100 machine will move to 100,100 but in "machine space" is 200,200. In such situation you can also do a g0 x-100,y-100.
How machine handle that?

Item 2

Underneath software works always in machine space (so you never need to touch software limits) when you ask for a G0 firmware should add to passed values the current origin offsets 100,100) and pass new positions to the engine (not sure if it is the so called planner).
When someone needs to read current position, the same offset is subtracted.
Handling in this way means that you have to add a variable to passed X before. When you change to a new "origin" you have just to modify variable value (and you don't care about previous offset like you do now).
I think you can consider this like a kinematic for cartesian systems.

Probably this change everything in Marlin since, as you said, it always worked using "working space" positions as base for everything while "real world" machine works in reverse mode. "working space" is at high level, the user level.

For a 3d printer, where usually you have home at negative X,Y values (endstop position) is like you have a predefined origin to "-X_MIN,-Y_MIN" so you bed corner is the user selected origin (an implicit G54).

Note that in "real world" machines when you set an origin to be active, also manual movements are related to such origin since often this is also the origin of the item where you have to work on.
Usually in laser/plasma/waterjet machines this is point where to start to cut on the plate.

To your first point (which I've labeled "Item 1" above) that seems to describe how Marlin works… At least, from the user perspective there is no difference.

The min/max positions are set in machine space in the configuration, and these numbers apply when in native machine space. When you change the coordinate system or use G92 to modify the current position we update the soft endstop limits (and the position_shift[X_AXIS] / workspace_offset[X_AXIS]) to match. The workspace_offset is used to convert back to machine space, when needed.

So, for example, if your MIN_X_POS (the physical limit) is set in configuration as -10, and your current_position[X_AXIS] == 0 then when you execute G92 X100 it changes current_position[X_AXIS] to 100 and the soft_endstop_min[X_AXIS] becomes 90. Also position_shift[X_AXIS] and workspace_offset[X_AXIS] will be 100.

It would indeed be possible to change the way Marlin works so that gcode_get_destination (etc.) subtracts the workspace offset right away, and then to change all other movement code so that it operates in native machine space, but this, again, is a very large task, and we are bound by legacy for now to having everything shift along with the coordinate system. This is mainly due, as mentioned, to this being baked into Marlin at the planner and stepper level.

There's a lot of code in Marlin that manages movement within the "logical" space. It would be a very interesting exercise to try and make everything work in native machine space. I suspect it would make the code smaller and more efficient. But it's a huge task, not for the timid.

Well this is what normaly doesn't happen. When you use G92 or G5x you don't need to change endstop limits. They should stay fixed (they are always related to machine space).
Following you example when you execute a G92 X100 and you are in position 0 you create an offset of +100 (as described in links you gave, note that in CNC I use it store -100 but is just a +/- reversed operation).
soft_endstop_min should keep -10 (changing values could lead to a bad stored value if not updated carefully in all situations). Current position should stay unchanged until displayed or sent via USB. When someone ask for current position this is the time to add/subtract active offset.
When someone ask for a positioning before assigning destination variables you should apply offset.
This way you work always whit system coordinate space and convert only when you need to output or input data (and also not continuosly change system space is safer and less prone to errors).
I understand that we all have to live with what have been done till now and there is lot of code to be changed (and a lot of bugs to put inside ;-) changing that).
I think that my idea is pure "ideological", too hard for me to put hands on and too heavy for devs like you, with already a big "weight" on shoulders.

Go on with path already present. Don't worry and thanks again for all your efforts you put in this project

How much work? We'll see as I give it a trial run….
A preliminary search gives…

• 222 instances of (LOGICAL|RAW)(_([XYZ]|CURRENT))?_POSITION.
• 497 instances of current_position.

Note that now endstop limits are not in range of machine space, they are in range of bed.
if home is -10,-10 and max is 300,300, and bed is 200x200 you can only move in range 0,0 -> 200x200 and if you use G92 this can be a problem.
If for example you move to 10,10 (20mm from home) and set G92 X0 Y0 you create an offset -10,-10.
If endstop is fixed to -10,-10 and you ask to move to -20,-20, subtracting your current -10,-10 offset you get -10,-10 and you can doit since it is into limits

Note that now endstop limits are not in range of machine space, they are in range of bed.

This is true. It was made into the default because, when printing, moves are constrained within the soft endstop range to prevent extruding off the bed. So, they are no longer just a safety feature to prevent the machine from hurting itself.

If for example you move to 10,10 (20mm from home) and set G92 X0 Y0 you create an offset -10,-10. If endstop is fixed to -10,-10 and you ask to move to -20,-20, subtracting your current -10,-10 offset you get -10,-10 and you can doit since it is into limits

If soft endstops are -10, -10, then after G1 X10 Y10\nG92 0 0 the min soft endstops will be -20, -20.

Anyway… The new PRs #8229 and #8234 take your point to heart and will have the machine operate in native space at the high level, making the code much more efficient! And, the soft endstops (and other coordinate values) will be in native space too, so they don't have to be tweaked in response to G92.

Anyway… The new PRs #8229 and #8234 take your point to heart and will have the machine operate in native space at the high level, making the code much more efficient! And, the soft endstops (and other coordinate values) will be in native space too, so they don't have to be tweaked in response to G92.

I think this implies the lower levels of the firmware (like the bed leveling systems) no longer need to operate in the LOGICAL space, right? They can just use the native coordinates of the machine, right?

What I'm thinking is the mesh for various bed leveling systems should always be in machine coordinates. And by the time the various movement() routines need to do something or provide a correction, they are being given the RAW coordinates and can just use what they get. Right?

I think this implies the lower levels of the firmware (like the bed leveling systems) no longer need to operate in the LOGICAL space, right? They can just use the native coordinates of the machine, right?

Correct. Everything internal will be in native machine space from now on. However, when reporting XYZ position output to serial (as with M114) the workspace_offset must be added on, and when taking input (as with G29 L[left] R[right] F[front] B[back]) the workspace_offset must be subtracted.

@thinkyhead ok about intrinsec security on endstop for 3dprinters but in CNC world machine should be still enable do move back from 0,0 (I think about waterjet, laser, plasma and milling machines)
Usually 0,0 in these machine is a reference to the piece to be handled or a point on the plate and this reference point can be also in the middle of them.
In this situation I think endstop logic must be changed

Usually 0,0 in these machine is a reference to the piece to be handled or a point on the plate and this reference point can be also in the middle of them. In this situation I think endstop logic must be changed.

If the endstops describe the bed... And the work piece is smaller than the bed (because it fits on the bed)... Why can't the endstop logic stay the same?

@Roxy-3D sorry forget to say 0,0 after apply G92
And endstops in such machine is the reacheable area

endstops must be in machine coords at all times. they define absolute limits of movement. 0,0 can be a limit, but it can also be moved and placed wherever you like within the endstops. I own a 4x8ft cnc.

currently with my machine, I will run a home operation which resets work coords to machine coords after finding where the endstops are. I think jog the machine to the location I want 0,0 to be, and reset the XY coords. This only changes the work coords. I then jog down unto my table or workpiece and reset Z to 0. depending on what I'm doing, Z will either go positive (0 on table) or negative (0 on work piece)

It's what I'm saying endstop are absolute positions on machine space (usually 0,0 is min but not always) but in 3d printers is different.
so if your home position is -10,-10 and max X/Y max pos is 300,300 but your bed is 200,200 you can never move there outside 0,0 -> 200,200 even if your machine is able to do that.
For printer can be ok, for CNC no

if your home position is -10,-10 and max X/Y max pos is 300,300 but your bed is 200,200 you can never move there outside 0,0 -> 200,200 even if your machine is able to do that.

1. Why would the max XY position be set to 300,300 for a bed that's only 200x200? If a machine is configured that way, I personally deny any responsibility for damage. 😁
2. When limits are configured and soft endstops are enabled, all G0/G1/G2/G3/G5 moves are clamped within the soft endstop limits, even if your machine is able to move farther.

@thinkyhead look at this https://www.thingiverse.com/thing:2487484
if you put a heated bed under it your max pos is bigger than it.
If you use it like printer you have a defined area that is not full machine area.
It's also true that it can be used g92 to define 0,0 as bed origin and work with such coordinate system