Thank you for joining the discussion. Always good to have the actual developer chime in.
If we were to do it correctly, it’s a function of f(L0,L1,L2,R1,R2, parameters) → L0, L1, L2. The best way to think of it is: If a single axis script is at 100%, then no matter what L1,L2,R1,R2 are doing, the contact point at the irl penis should be at 100% (and not 114% → slip out). I would probably derate the corrections with L0 < 50% (to be defined) since at 0% the correction is not possible or sensible.
For Firmware vs. Software, I’ve already laid out my main arguments. Since there are individual, day- and sleeve-dependent parameters, the more logical solution would be in software. Additionally, although the EEPROM should take a few cycles, I’m not a fan of re-flashing every time.
Hardware changes would introduce new receiver mechanics (doable, but everyone who wants the functionality will need new parts) with new points of failure, added weight to the moving mass, and also have the following issue:
The most lowest position would be pretty painful for the user, if it makes contact, since there has to be some hard plastic or a screw or something in the same plane as the entry of the sleeve. That the toy protrudes a bit like today does have the upside, that it’s the sleeve making contact first while keeping the plastic away from the user. (Think of grinding motions getting literal). If we put a cushion on it, then the sleeve entry does not reach the bottom, if so configured.
The theoretical argument: Yes, since there can be more bandwidth around the sensitive tip of the penis without using smart limits as of today and/or large safety margins and still be safe. Both in that the contact and pressure points can be more varied due to the additional axes being able to fully engage at the very tip. As well as with L0 still reaching the tip, if everything else is centered. And lastly, if someone wants to fully experience the memory of his belly dancer ex, this makes it possible 
Anecdotal Argument: I have tried a fourth option in the meantime: An extension in OFS to stunt L0 depending on the other axes, deactivating Smart Limits and minimizing the safety margin. I can personally say, that it makes a huge difference even with only an OSR2+Twist, although I have not yet heard back from anyone else trying it.(It is quite risky trying that for the first time with a full script, since the appropriate safety margin will hinge on the individual mechanical setup and its stiffness)
I think before we go at any other implementation, the fourth option is a quick and dirty way (that necessitates more script versions) to get feedback from. I will probably release the extension soon - I just jumbled up something to try for myself and want to include more functionalities - and hope to get some feedback from more users. This way the question of how noticeable/useful this is, can be answered with more statistical weight to it.