Unless something changed very recently neither vim nor neovim defaults to storing persistent undo files in ~/.cache. It's application state, not cached data.
The undodir option in vim defaults to the directory of the file, and in neovim it defaults to ~/.local/state/nvim/undo/.
What did OP misunderstand? I am not sure how and where their understanding of "persistent undo" is different from "persistent across process restarts"?
Nobody should have to read release notes to avoid data loss; there should never be a change such that someone who hasn't read the release notes (or missed a detail in reading them) to avoid such a problem.
You're holding others to a standard that you yourself haven't adhered to. Please go read the release notes. No mention anywhere that old undo data will be deleted.
Also, what's up with people claiming that the undo files are stored under ~/.cache? That's completely made up. Or that persistent undo doesn't persist edit history, against what the docs say. Utter nonsense.
The lifetime of files in ~/.cache/ is the same as what the FHS documents for /var/cache [0]:
> Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.
Meaning: the persistence of such files is not guaranteed across application restarts. If vim (and also neovim) had intended for the undo files to outlive the program, the files should have been put in ~/.local/state instead -- as also explicitly documented by the XDG [1]:
> [XDG_STATE_HOME] may contain: [..] current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.
You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.
There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".
> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever
But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.
Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.
They live in ~/.cache which is defined as "user-specific non-essential (cached) data".
Despite this user's impressive résumé, they simply misunderstood the feature.