What's the reason video editing is not lossless by default?
You cannot make frame-precise cuts within this sequence unless you wish to carry on the frames that won't be visible (and I don't think anyone tries to do these cuts by keeping some invisible frames), so you only get to make such edits that always include the first I-frame of the sequence.
Therefore if you want to make completely lossless edits your editing precision is lost. For frame-precise editing one usually ends up re-encoding the stream.
Of course, you could only re-encode only the GoPs that get broken while keeping the rest intact, and I guess this would be better and a lot faster than re-encoding everything. I don't know if any application tries to do this. But that is also a bit troublesome, as you'd like to use the same encoding parameters—and maybe the same encoder—as the other frames, to not have quality differences between the edits and original.
LosslessCut does have experimental support for this partial re-encode called "smart cut" [1]. Since it's using ffmpeg internally, the challenge become how to instruct ffmpeg to do this[2]?
It's far too fast to be re-encoding the whole video and is too precise to be cutting at the nearest keyframe.
It has limited codec and container support, though.
Correct! For example, if you trim the end of a video in the middle of a GOP, it includes the entire GOP as is, but only plays up to the point where you trimmed.
I'd for sure rather have tools that actually do what they claim to do. Using container metadata tricks feels to me as lazy and misleading to the user.
My experience shows that if you try, this confuses and breaks many (especially hardware) players trying to play that file.
That's exactly what VidCutter does.
There are a few caveats, though. Examples: (1) You're limited to cuts-only edits. (2) Because the base unit of video encoded for distribution is a GOP¹, edits either have to happen on GOP boundaries (i.e. at a keyframe) or the apps have to re-encode the GOP.