1. I understood your point to be "Well why isn't HTTP layer 6?" or "Why isn't layer 6 used?" which makes no sense as TLS is layer 6, and HTTP (and the web service) is layer 7. They necessitate each other. Simply stating that X and Y are different parts of the OSI model are not arguments toward the format of a protocol in one layer.
2. My argument isn't "just because you can", it's "you can." You seemed to be saying it would be difficult if not impossible. I was saying, no it isn't.
3. Endianess will always be an issue, forever. The only time it will go away is when every architecture picks one format. It's a really simple operation and it's part of how computers expect us to behave due to their nature and design. Hacking around it doesn't make it disappear, nor does it help anything.
4. What old records? Pragma was deprecated in 1.1 yet included anyway for god knows why. There's no reason they should do so again, but if they do, it will exist both in text and non-text versions. This is a non-issue.
5.
> a protocol on the Internet needs to interoperable with many systems
You mean like IP, ICMP, TCP and UDP?
> But human operators are still going to have to program those systems
Yep.
> and ASCII is a useful representation which enables us to do just that
Sure. My C code editor displays ASCII. It totally enables me to write IP, TCP and UDP code, using an ASCII display with code in ASCII. And it neatly compiles down to binary and runs a binary protocol. Amazing!!!! (seriously though, if your argument is that ASCII is just easier to "program" as a protocol, you're up shit creek; you have to write more code to handle converting ASCII to binary and back anyway. your high-level language abstractions hide this fact from you, and you think it's a convenience because you never have to learn what a constant is)
> it's a problem to servers and quite a huge one at that for intermediaries
That's backwards compatibility for you. If the alternative is to simply mangle and bungle the existing format into a frankenstein into eternity, it's not going to be any better.
6. Are you comparing extending HTTP/1.1 for a single feature to the backwards-compatibility support of HTTP/2.0? Because that makes no sense. The vehicle analogy is just weird at this point.
7. See, this is where the vehicle analogy works again. "leveraging existing mechanisms". In other words, let's throw one more feature on top. It never ends, because all you have to do is keep adding more lines, and modify the browser, and modify either the server or your web app, and keep going to support god knows what. At some point they'll implement an incredibly complex binary protocol and embed it in base64-encoded ASCII HTTP/1.1 headers, because "leveraging existing technologies" is thought of as a neat thing to do. It will also be insane. At some point you need to just make a better <whatever> instead of hacking and hacking and hacking onto it to make it do what you want.
Like building the great pyramid of Giza out of tinker toys. Sure, it's easier for people to use tinker toys. It's easy to understand. You don't have to do any real work. And it's also not meant for that task. At some point you need to throw out the toys and use stone.
I can even go further. ASCII is too old to use. Really, it's been antiquated by UTF-8. It is telegraphic codes for teleprinters. And ASCII itself was micro-optimized to only be 7 bits, and the 8th bit was used as a parity bit because perforated tape had space for 8. ASCII is so antiquated (1960) that nobody should be using it anymore.
Clearly we need to implement HTTP/2.0 in UTF-8 wide characters, so connections to China, Japan and India will support their native language in the protocol. (After all, what's the point of a native-language protocol if only English speakers can read it?) Also, we should include the byte order mark at the beginning of all messages so we don't have to worry about how endianess works.