Another issue here is bed leveling / auto calibration.
Even given gcodes in X,Y, and Z, one must apply a rotation transformation to them at runtime to account for an unlevel bed. This turns out to be a trivial matrix multiplication operation when working in xyz-space. But I'm not positive it can be done quite that simply in delta coordinates. It would definitely be a good idea to look into this beforehand, because you're not going to gain anything if it turns out that accounting for the bed plane means converting to cartesian, rotating, and then converting back to delta coordinates. The above is only really relevant if using an auto-leveling system though.
But I think a bigger issue is that it forces the slicer to take on an entirely new role. Anyone developing even a slightly different motion system for 3d printers would need to edit every slicer on the market to add support for their printer, whereas currently, they only really need to add support into one firmware.
Even given gcodes in X,Y, and Z, one must apply a rotation transformation to them at runtime to account for an unlevel bed. This turns out to be a trivial matrix multiplication operation when working in xyz-space. But I'm not positive it can be done quite that simply in delta coordinates. It would definitely be a good idea to look into this beforehand, because you're not going to gain anything if it turns out that accounting for the bed plane means converting to cartesian, rotating, and then converting back to delta coordinates. The above is only really relevant if using an auto-leveling system though.
But I think a bigger issue is that it forces the slicer to take on an entirely new role. Anyone developing even a slightly different motion system for 3d printers would need to edit every slicer on the market to add support for their printer, whereas currently, they only really need to add support into one firmware.