This reminds me of Gentoo/Arch and takes a little getting used to. In a nutshell as I see it, ignore the version number as meaningless. Think of it like a git commit, the only time you need it is when bad stuff happens. Lets look at it a little differently, again I think I am on the right track here from the way I have been using it and watching it work.
I think, if I am correct on this, the OS version follows a git branch pattern where your mixin is a feature branch that you merge into master, which could be considered the running version. You just look at the version/commit hash before the merge and after. If this is the case then maybe they should just scrape or at the very least redo the docs to use a better diagram description.
Again, the version thing does not bother me and how they are doing updates from the code I have looked at makes sense. The system knows what is installed and what it is responsible for and it will ensure those bits are updated in the case where you did a mixin and side loaded your package.
A mix can be thought of as a fork. You took a clear linux install at a known point in time, add some stuff to it and continue on from that point, doing a pull from the upstream only when you want. This requires you to mange your own upstream/update path in effect. This could also be thought of something like an internal package repo where a company uses an LTS base distro but then turns off all external repos and says all updates have to come from the internal repos only and basically makes themselves the update path of record. The company may only update certain packages or pull in only what they want based upon their own schedule.
Again, I may in left field here but that is what I gather from the docs/code and what I have seen doing mixin’s in my system.