I love to see a seemingly simple game end up having interesting movement quirks.
I have to get to bed, but, there is a little more to optimizing the movement here. Your lua is nice but I found something it's lacking is a "diff" display, as in, the amount that your X position has changed from the previous frame. Normally that would be your x speed, but during the glitchy boosts, your x speed doesn't properly reflect how far you go. Adding a diff made it easier to tell the maximum length of the boosts, and also if I was dipping below 1.5 when starting them.
(I also changed to decimals instead of it being out of 256, "1.128" meaning 1.5 isn't my style)
I did have the character sprite disappearing 2 frames earlier in level 1, yet it didn't save any frames on the Start press to go to level 2; possible frame rule? But I had only applied these techniques to the last few jumps of level 1, so there's potential if it's applied from the start.
As an example, here when starting this boost, your movie has a frame of 1.164 difference, in between a 1.5 and a 1.984:
If I just add an extra Right input the frame the jump starts, instead of 1.5, 1.164, 1.984... it's 1.5, 1.5, 1.672, 1.984...
This ends up being .023 subpixels better. A small amount to be sure, but it adds up, and this happened to be a weak jump; in a different spot, when on the second jump of a boost section, I had a diff of 2.277 for one frame in place of the 1.672. (It's possible chaining as many small jumps as possible during the boost section could be valuable, if these 2+ diffs happen only then)
I also tested letting go of R outside of the 20-80 area. If you oscillate R, you get very very slight subpixel increases in the diff from fd->20.
I'm using Bizhawk so I changed your Lua to use read_s8 for signed bytes so this won't work in fceux but here
https://pastebin.com/pZH2SSb6
this is the important bit:
XDiff = (X + (XSub/256)) - PrevX;
PrevX = (X + (XSub/256));
I hope you're excited about this new movement development!!!
I have a crazy idea for a Lua to help with keeping track of the best results for these jumps, since it's so SO tedious to compare "2822.996" to "2822.984" and what not. A table the size of the movie that keeps the highest X position it's ever seen on that frame, and colors your X position accordingly. (like green = new best, white = tie, red = slower than its seen before) And then you could try different patterns of Right inputs or jump heights and what not, then go to like, the 80+ area where the boost is done, and make sure what you just did is actually a better position just by seeing if the X is green. Would you be interested in that?
The oscillation idea wasn't needed, because it seems like the distance you gain from it accumulates if you don't do it (like oscillating gets you 1.512 instead of 1.5, but if you hold off, you'd get 1.524, hold off again 1.536, etc). So the first frame you let go in midair, you get all of that accumulated distance regardless. I also didn't get anything out of extra Right presses after the jump.
I mainly improved the distance just by starting the boosting at 0x08 instead of 0x20. It does take more Right presses, but any frames where you can move at higher than 1.5 is worth it. This saved a few frames on every boost section.
But I think this would fall under "laboursome optimizations that can't actually be noticed under normal viewing conditions". I certainly felt laboured going at this first level for a few hours. For the strategy used, the play is not sloppy at all, and I would say it should still be published. (Though if you're not interested, a V2 is going on my eventual projects list...)
My advice for the future is to have a very readable way (through Lua) of telling how much distance you're traveling if 'xspeed' is unreliable, and when it comes to moving at speeds higher than a speed cap, don't dismiss brief bursts in favor of longer stretches, any speed increase can be useful.