When setting accelerations and speeds in your slicer, they’re emitted into the gcode for each feature type (e.g. perimeter, infill, etc). If I wanted to tweak certain accelerations during a print, changing it with manually inputted gcodes is reset every time there’s a feature change. I was considering a way the slicer and printer could be integrated, with the beginning of a gcode file specifying the different line types and speeds/accelerations for them. Then, when printing, the slicer needs only emit the line type to the gcode, and the printer can apply the speeds. The advantage to this is that you could change the variables during the print (similar to how when using firmware retraction, you can change the retraction amount during a print), and not have them get overwritten immediately by the next feature change.
A relatively simple way to implement something like this is with a post-processor script for the slicer, and setting the speeds in the slicer to different non-round numbers so they can be told apart by the post-processor script and replaced by variables. I understand that this feature is somewhat niche, but it’s something that I would definitely use. (As a bonus it could be incorporated into the GUI similar to the firmware retraction showing in mainsail)