You're likely thinking of the point when the TLS 1.3 core protocol design was finished, but they were experimenting to understand deployability. This is long before the TLS 1.3 protocol your browser uses today was finished, and that is about half a year earlier than RFC 8446 was published. So any "guinea pigs" in this experiment know what they're getting into, likely people explicitly working on, or in a group tasked with supporting, TLS 1.3. This is like that Windows 95 era but instead of buying random Windows software in a Best Buy to check it works on Win95 before you ship it, you are raising Purchase Orders to buy the "Best Security Office SSL Protection Plus" or whatever to check what it does with your prototype TLS 1.3 stack.
The most important thing expected and confirmed in the deployability testing is that many of the middleboxes were allergic to new TLS versions de facto. TLS says clients announce the maximum "version" of SSL they can do, then a server chooses the same or any lower version e.g. 0x0303 means SSL 3.3 which in reality is named TLS 1.2. However most middleboxes react to any version they don't understand by freaking out, so you can't ever say you speak a newer version. The initial TLS 1.3 design chooses 0x0304 with 0x0400 also a possibility, but neither would be deployable for this reason.
The most important surprise was that middleboxes are so reluctant to allow people's web browsing to just break that they mostly instead don't implement any meaningful security at all in a certain edge case. This is surprising to an engineer but makes sense once you understand their business (they sell tiger-deterring rocks, they don't sell tiger insurance, so they don't care that the rocks don't work, they're relying on the fact that there probably aren't any tigers and if there are too bad for you trusting their useless rocks).
As a result of this insight RFC 8446 TLS 1.3 connections actually start like this:
1.3 Client: Hello some-server-name, I'm the TLS 1.2 client you were talking to earlier, just resuming our earlier conversation number #random-nonsense. Also, just thought you might like to know I support optional FLY CASUAL THIS IS TLS 1.3 with a bunch of parameters
1.3 Server: Hello, yes let's resume our conversation. I too know FLY CASUAL THIS IS TLS 1.3 and I've got a different bunch of parameters.
And then everything is encrypted. Which makes sense, we said we're resuming a TLS 1.2 conversation, of course those are encrypted, nothing to see here, if the middlebox tampers with it that'll break people's web browsing. But actually the DH key agreement parameters for the session were in that optional extension and we aren't talking TLS 1.2 at all.