Ok. So... I found the issue. It's a one-line fix, and eventually I'll get a patch out to y'all (I don't control the timetable for patches, but whenever NI schedules the next one, I'll put this in it).
The bug only affects a brand newly created VI from a template -- so, new VI for dyn dispatch, static dispatch, and override are all impacted. (Just occurred to me that I didn't test new from .vit, but for the moment, let's assume those are impacted also.) The bug prevents docmods from being set on the newly created VIs. So when you create a VI, you can make all sorts of edits to it, and when you hit ctrl+shift+s the first time, it will save because it doesn't yet have a path on disk and that will trigger saving. But later edits don't mark the VI as having unsaved changes. If you hit ctrl+s to explicitly save the VI, it will save. But if you hit ctrl+shift+s to save all unsaved VIs, it won't be included in the set.
This only affects new VIs from templates. If you create a new blank VI, no problem. If you unload the project and reload, all the loaded VIs start normal document management correctly.
So your workaround is to use ctrl+s often instead of ctrl+shift+s. And that sucks as a workaround, but it's the best I can offer at the moment.
"Hey, AQ, why does a mode even exist where a VI can be edited and just doesn't get docmods?"
Yeah, you know the feature where you can use Open VI Reference to open a VI and not track changes for scripting? I found that I could dramatically improve performance of massive cloning operations by turning on that flag at the start of the operation. I just didn't remember to turn it off again at the end of the operation. So the newly created VIs behave as if they have an open VI ref that said not to track changes.
One stupid line of code.
"Why didn't your autotesting catch it?"
Well, I have tests for "create new VI, make a change, save it to disk, load, verify the thing that saved loads", but they all use explicit save of the VI, which saves regardless of whether there have been any changes or not. It's not something I've typically had to worry about -- I've never managed to break LabVIEW in this particular way before.
I'm sorry for the pain. Use the workaround, please.
Search LabVIEW like a graph! 
