I'm a bit confused here... Also would not mind having @Brecht Van Lommel (brecht) or @Campbell Barton (campbellbarton) thoughts on this.

If I understand this patch correctly, you force storing that value in .blend files under a 'false' name that is not even used at all in Blender? I would rather avoid that tbh...

At the very least, I would rename the variable in DNA struct to match new name then - yes, it will be a noisy commit, but at least consistency between current codebase and .blend files it produces would be kept?

Is there no more straightforward solution to this, like clearing the pointer on old files or changing the name?

In D9442#234402, @Brecht Van Lommel (brecht) wrote:

Is there no more straightforward solution to this, like clearing the pointer on old files or changing the name?

How could we clear the pointer? Old versions (since 2.80) didn't clear this, which was the initial mistake, but we'd have to do it on read.

Changing the name is possible, but I'd prefer to keep the current name. That's why I first went for this proposal to just rename it in SDNA.
I actually do think this is a straightforward solution, it's just that the initial problem is a bit difficult to grasp. (Maybe the code comment should be shorter and just reference the task/diff to avoid confusion.)

In D9442#234400, @Bastien Montagne (mont29) wrote:

If I understand this patch correctly, you force storing that value in .blend files under a 'false' name that is not even used at all in Blender? I would rather avoid that tbh...

That's how the renaming code works. DNA still stores the old names (e.g. bTheme.toops) that are not used at all in current Blender. But when reading it, DNA maps it to the new name as an alias (e.g. bTheme.space_outliner).