It's indeed odd. I'll look into this, though this is a low priority issue, so if it takes more than 10 minutes, I'll postpone it as a linq issue and your queryspec issue is more important.
It doesn't seem it has any impact on the project behavior.
(edit) the project stores defaults per element. These are loaded from the section discussed here. When you save the project, it writes them out as <Defaults>. When some setting changes, it writes that instead (as the defaults changed). When you load it again, it stores these values as 'Defaults' and the process restarts.
Question now is of course, why a changed set isn't written as '<Defaults>' as well.
(edit). The defaults per element are stored inside OutputSettingValues containers, which are objects which serialize themselves and which contain settings for a given element type, in this case the default values for a given element type. When they're loaded from the file, these containers have the xmlElementName 'Defaults'. When you save the project, this elementname is used for the xml element name which represents the outputsettingvalues container, so this is 'Defaults' initially, but when a setting changes, the container in question gets its xmlElementName changed to 'OutputSettingValues'. I assume this happens because the container is simply replaced, and by default the container has the name 'OutputSettingValues' as xmlElementName.
When the project is saved then, the xmlelementname is 'OutputSettingValues' so this causes the difference. As only containers which contain any values are serialized, it becomes visible, the others (which are empty) would still be serialized as 'Defaults' (but as they're empty, they're not).
5 minutes left, so I'll check whether I can find where to change the changed container xml name after the change
(edit) fixed. The clone method of OutputSettingValues didn't pass in the xmlelementname to use and reverted to the default. The clone was altered in the ui of the settings, so ended up in the project settings. Fixed in build July 18th