Browsers have legacy support but HTLM5 is not backward compatible, you can’t open a HTML5 page in IE5 .
The best you can do is keep using the old protocol for a while so that most clients are compatible when you do the switch. That is what we had, messages were versioned, and we were able to support older versions while sending new ones.
When we started using it, we announced that it will make new messages unreadable to older versions after n releases, and the debate on backward compatibility started. It was the change in the way message-id are calculated. The proper solution IMO would have been to make the fix in v1 message-type like we did, AND prepare a v2 free of legacy, on which we would have switched after n releases. But the PR at the time only did the later, while the debate ended up on the decision to do the former. That first fix became the model.
Having the communication protocol in the js thread with limited capabilities also lead to poor decisions like using transit on the wire, because it is an order of magnitude faster to parse for clojurescript compared to json. But having the protocol on status-go, we could have used protobuf and json and eventually pass transit to status-react. Back then we were somehow much more reluctant to move anything beyond go-ethereum patches to status-go.