After digging a little more into the settings issue, I think I have characterized the behavior.
So, once the settings file gets in this weird state, the settings_id still looks good. But if you call has, it will return False even if the settings key is in the settings file. If you call get, even when you provide a default, you will get None.
So for some reason, has will tell you that there is no key, but if you provide a default to get, it will find the key with a value of None (as if it existed with a None value) and not apply the default. But once you call either has or get, the subsequent has or get will return the proper response regardless of the faulty response before.
In my case it is happening in this plugin github.com/facelessuser/SerializedDataConverter. I am not sure what this plugin is particularly doing to put the the settings file in a weird state, but it is very reproducible. I suspect it is an API bug.