Without digging into the actual details, I presume this is because the need for lookahead into future frames to decode B-frames Makes It Complicated.
And I’m not sure offhand if that’s fixable with a little extra work, or something that’s fundamentally hard in the current MLT architecture.
In general no, as with things like variable frame rate they can increase compression efficiency - which is a good thing when distributing a ‘final’ produced video to many users - but complicate some tasks, like decoding, and post processing.
So for now, if you want to use the time remapping on such a file, it looks like you’ll need to transcode it to a working copy using only I and P frames.
I assume this just fools the test that shows you the warning. Which is probably “a bug” - but I doubt it will save you from whatever awful frame glitching can happen if you try to remap something with B-frames.
That one is a UI bug that’s bugged me for a while too. What happens is when you change the value, it moves the keyframe without moving the current position cursor - so the cursor is no longer on a keyframe, so you can’t change the position of the keyframe again until the cursor is back on the one you want to change.
You should be able to enter values explicitly too, but it looks like that responds immediately to anything you type in there, as you type it - which does all sorts of weird and horrible things.
I see a huge opportunity for someone, especially a beginner, to make some valuable contributions there.
Aside from just the limited time thing, experts - and especially The Expert who implemented some thing, or helped to design it - can be the worst people, and have the hardest time, writing documentation for other users.
It’s a sort of fundamental thing - when you know Too Much about How It All Works, it can be hard to figure out what people who don’t know that will most need explaining. Your assumptions about What Is Obvious are not the same as theirs - so it’s really easy to both not explain enough, and to waffle on way too much about things that are obvious, or are so niche most people won’t care and will just be confused while first trying to understand the basics.
So the best documentation always comes from a feedback loop, with relative novices trying to explain what they misunderstood or had to learn the hard way, and ‘experts’ correcting any misconceptions in those explanations.
