I think the answer (read from between the lines) is more: "There is no way to make it work for the general case of all video formats, and we don't implement a feature unless it works for the general case, so we choose not to implement it at all. If that means that we don't have that feature for the file formats where it would works, that's a sacrifice that we are willing to take."
> we don't implement a feature unless it works for the general cas
I used to make that mistake a lot. My boss would say "can we do this", for example report memory usage per operation. And I would say "no because sometimes memory is shared between operations so it would be meaningless". In other words I couldn't do it perfectly so I said we couldn't do it at all.
That's what the VLC guy is doing and I didn't realise until I worked with that boss that it is COMPLETELY WRONG!
Just because you can't do it perfectly doesn't mean giving up entirely is the best you can do. In cases like this you can absolutely do something that works sometimes but not in every case and that is way better for users than just giving up.
Exactly an in this case it even works 99.99% and VLC already has a related feature (seeking to a specific time) that has pretty much the same codec requirements.
Except even that answer makes no sense since VLC implements time-based seeking which has the same requirements as seeking to a specific frame number. The only additional part to implement is automatically skipping forward a number of frames after the closest preceeding seek point.
Adding a requirement of supporting this perfectly with literally all formats you can think of is not reasonable at all since a video player that stuck to that principle would not be able to support any controls at all. It's the kind of bullshit excuse developers or corporations like to give when they don't want to implement something but also don't want to be honest about that.
