Three proposals today, all about what you are allowed to forget
Three unrelated protocols put out three unrelated documents today, and read together they are all answering the same question from different ends: what does this system actually have to keep, and who has to keep it?
Ethereum proposed keeping less. EIP-8383 cuts the beacon block retention window from 33,024 epochs to 8,192 — roughly fourteen months of history down to roughly four — on the argument that the larger number was derived from a worst-case parameter nobody uses in practice.
Bitcoin proposed keeping more, or rather keeping something it had been quietly assuming would look after itself. BIP-138 specifies an encrypted backup format for output script descriptors and wallet policies — everything about a wallet except the keys — with an explicit prohibition on the payload containing private key material.
XRPL moved to make some things unkeepable by third parties: a prerelease codec shipped definitions for Confidential MPT, which takes a token type on a public ledger and makes amounts or holders not plainly readable.

Three different answers to who bears the cost
The Ethereum change is about the cost of participation. Retention requirements are paid in disk by everyone running a node, and disk is one of the few hard limits on how many people can. The proposal's whole argument is that nine tenths of that cost was buying a safety margin for a parameter that is never selected. It is a rare kind of improvement — one that makes the rule match what the system was already relying on.
The Bitcoin change is about the cost of loss, and it corrects a category error that has been sitting in the culture for years. "Back up your seed" is true and incomplete: the seed restores the keys, and the descriptor restores the knowledge of which outputs are yours. Separating them is what allows different storage decisions for each — and the rule that the encrypted payload must never contain key material is what makes the separation enforceable rather than aspirational.
The XRPL change is about the cost of publicity. A public ledger's defining property is that everyone keeps everything about everyone; confidentiality features are an admission that this property, taken literally, is unusable for a class of real transactions. The thing worth watching is not the cryptography but the second-order effect: every compliance process, explorer and analytics product built on the assumption of readability is built on something the protocol is now selectively withdrawing.
The pattern, and its limit
Each of the three is a system deciding, years after launch, that a default set early was set wrong — too much retention, too narrow a backup, too much visibility. That is a healthy sign rather than a worrying one: defaults chosen before there were users are defaults chosen without evidence, and revisiting them is what evidence is for.
But two of the three are drafts and one is a prerelease. EIP-8383 has no client commitment, BIP-138 has a number and test vectors and nothing else, and the XRPL codec is on a branch named for a different feature. Nothing described here has changed anyone's node, wallet or ledger today. What has changed is what three sets of maintainers are now arguing about — which, on a slow enough clock, is the better leading indicator.