It's not about what you could theoretically do "on the line" - nobody cares. Over and over again: it's the ecosystem. It's not hard, but as long as you refuse to consider the ecosystem or don't even see what that means, failure of this UCIv2 is probably the best outcome of this endeavour.
I believe I understand you; I think we're just talking past each other. I'm not trying to challenge the primacy of an ecosystem: a healthy ecosystem is absolutely necessary, because the actual experience using the software is the only thing that ultimately matters. My point is that
the UCI ecosystem is already fragmented.
There is variation in clients' and engines' interpretations of the informal specification, variation in strictness, and wide variation in feature support (go nodes, multipv, ...). For example, some clients require the pv to be at the end of info, some don't. Some clients require multipv to always be present when the pv is present, some don't. Some clients send "go depth 245" when they want an infinite search,* some send "go infinite".
Clients and engines currently have different (incompatible) assumptions and requirements, so things are already broken. Codifying a particular behavior doesn't change that either way. (And it can never prevent people from making additions or modifications, or writing half-implementations.) However, it might make it easier for people to converge.
Admittedly, if you restrict the "UCI ecosystem" to popular engines and clients that are 5 or more years old, it is probably less fragmented than what I observe working with brand new clients and new engines. I'm motivated by the observation that new engine developers often have to make fixes or write hacks whenever they want to use a new client.
The indictment could be made, "they simply misunderstood the specification" or "they were lazy" or "they wrote an incorrect implementation", and those are all likely true! I'm interested in why that happens and what can be done to reduce the chance of it.
What seems most useful for new engine and client developers is a set of tests that would tell you exactly what your engine (or client) does correctly and what it gets wrong. That first requires deciding exactly what may or may not be assumed by engines and clients. (So my ruckus about "protocol version 2" is mostly just a prelude to what I hope will be the beneficial thing.)
I lean toward asking more from clients in order to simplify engine implementation because there are fewer clients than engines. I'm planning to reach out to client developers and ask them if they'd be willing to make their clients more careful or lenient (if needed), and then I want to help them in whatever way I can.
At least, that's the long-term vision. I expect a project like this to take several years. And maybe, like you say, it would be better if it failed.
*This happens to be Stockfish's maximum depth, so I assume that's where the number came from.
