I want to avoid parsing it!

But for a lot of use cases you can't completely do that, right (honest question)? Say a flumeview reduce thing scanned to a certain entry inside a nested map. Now you still need to parse that value so that the flumeview can access it (for example if it's a map and you want logarithmic lookup time, there's no way around parsing since you can't do binary search on the encoding).

I think I get what you want to do, and I see a lot of the benefits, but at the end of the day it is still a detail of a single implementation choice among many. It's hard to justify that complicating the signing process (and that's what this is fundamentally about - db encodings can change, even the transport encodings can change, but it's the signing encoding that we are going to be stuck with).

If you where hypothetically gonna specify a length delimited version,
as I'll need to actually make this to test whether it is faster or not, what would it look like?

Whatever you want it to look like. The simplest approach would specify lengths instead of sizes at the beginning of arrays, sets, objects, but using exactly the same encoding otherwise. You'd just set and interpret those values differently than the size-based version.