RFC 7924[0] (cached certificate extension) is intended only to avoid lots of wasted bandwidth re-sending certificates, but with a modification of where the cached_info goes in the handshake, it would make any middle-box meddling (including censorship) orders of magnitude more expensive.
Honestly, the next version of TLS should have a mandatory variant of certificate caching [0], except instead of putting the cached_info in the ClientHello message, the final handshake message (which is encrypted) would include the hash of the cached certificate. If the hash doesn't match, then the server would send the certificate (the connection is now in an encrypted but unauthenticated state).
If nothing is cached, the client sends randomly generated bits in place of a cached certificate hash, which eliminates one case to be handled in the protocol. (Handle an empty cache and a stale cache in the same code branch.) This provides more privacy than sending an "I have nothing cached" and it's more likely to be struck by lightning and a meteorite simultaneously than get a 256-bit collision. The consequences of a hash collision are only that the connection needs to be reset.
In the case of nothing being cached, again to reduce the number of special cases to handle, the client would need to make a guess as to the ECDH/RLWE/etc. parameters in its initial handshake message. The mechanism for handling stale cached ECDH/RLWE/etc. parameters would then apply to the non-cached case. (In this case, the server just sends back a message saying "Those are stale. Here are my parameters for a method in your provided list of supported methods, and here, also have my first side of the handshake."). Again, eliminating special cases by faking it/guessing if nothing is cached slightly increases privacy by requiring information outside of the handshake to detect if this is a repeat visit.
This change would force any meddling middle box to go through MITM'ing most of a TLS handshake before getting much information at all, and then having to break the MITM'd connection and allowlist/denylist* the involved IP for some period of time. For scalability, most present-day censoring hardware keeps the censorship out of the main path, passively observing traffic from a router's cloned port, and submitting forged RST packets to both sides of a TCP connection when the plain text contains something it doesn't like. Forcing MITM'ing makes such meddling orders of magnitude more expensive to implement, and much less accurate in cases of shared IP addresses.
On a side note, I heavily use the trick of initializing a cache to expired values in order to avoid special-casing empty caches. There's a cute trick for caching conversion of ISO-formatted date strings to date objects if your hot path includes a lot of parsing of dates from JSON and only dealing with consecutive days (in my case, yesterday and today) the least significant bit of the rightmost day digit code point and the least significant bit of the rightmost month digit code point form a very cheap 2-bit hash that never collides for consecutive dates, so you can use a 4-element array as your cache. These digits are at constant offsets in the ISO date string from the year 1000 to the year 9999. (There are no consecutive even days, and consecutive odd days only occur when the month rolls over. Months always alternate even and odd, even at the rollover from 12-31 to 01-01. Every character set I'm aware of puts the digits consecutively, so this trick works for unicode, ASCII, and every character set I'm aware of.)
[0] https://tools.ietf.org/html/rfc7924
* formerly known as whitelist/blacklist