The duplication of defaults would indeed be great to solve, and should simplify versioning nicely.

Maybe it makes sense to have files like DNA_scene_defaults.h next to DNA_scene_types.h?

Also not sure e.g. View3DShading defaults should be defined as nested struct in scene. Seems more clear if we define all struct defaults separately following DNA header organization, even if it's a bit more verbose.

@Brecht Van Lommel (brecht), do you mean to define the structs as macros?

eg:

#define DNA_DEFAULT_View3DCursor { \
    .rotation_mode = ROT_MODE_XYZ, \
    .rotation_quaternion = {1, 0, 0, 0}, \
    .rotation_axis = {0, 1, 0}, \
}

#define DNA_DEFAULT_RenderData { \
    .mode = R_OSA, \
    /* snip */ \
}

#define DNA_DEFAULT_Scene { \
    .cursor = DNA_DEFAULT_View3DCursor, \
    .r = DNA_DEFAULT_RenderData, \
    /* snip */ \
}

Think it can work nicely, it has the advantage that a struct like View3DShading thats used in multiple places can have a single define.

Note that we wouldn't want defines from from DNA_*_defaults.h being instantiated many times - ideally only once for ID types.

Ah, I thought .shading = DNA_Default_View3DShading, would work. Apparently in C++ but not C.

The macro seems like a good trick for structs that are embedded multiple times.

Would it be possible, when "Reset to Default Value" to first read from these new default structs and then also see if there is an overriding value in the current startup blend file? That way, initially, I will always get our current factory defaults. But I can then make a bunch of changes, then "File / Defaults / Save Startup File" and then it is those values that will be used when "reseting to defaults". Of course I can always File / Defaults / Load Factory Settings and will be back to normal.

Otherwise I fear that some users might have a different idea of what a "default" is and expect their value if they have set new "defaults".