Five of these six match what we ran into building the Collective Ontology at ML Systems, an ontology for taking houses apart and rebuilding them. Mistake 5 is the one I'd push on, because it depends on what an old version is.

If an old revision is a superseded record, the Time Machine is right: keep one current object, version it elsewhere. But if the old value is evidence, deleting it destroys information. Our house is described by a town assessor record, a homeowner's memory, imagery, and seven AI agents, and they disagree constantly. When a crew measures the roof and finds two shingle layers where the homeowner said one, the homeowner's claim is demoted, not deleted, because the fact that the homeowner believed it is itself information about the house, and it changes what a lender or an inspector should ask next. So the ontology stores claims rather than facts: each carries its source, an evidence grade (MEASURED > STATED > RECORD > MODELED), and a verification state. The current value is a derived view over that, not the only thing kept.

The "model reality, not the source data" principle is the one that becomes hard when the sources disagree about reality. Our answer was to scope authority to a domain (the assessor is authoritative on legal and valuation facts, vision on the visible envelope, the homeowner on intent and recent work) and to let two credible sources resolve to a conflict state that stays visible, rather than pick a winner with a global writeback rule.

And the "building that is also a schedulable resource" example is exactly our case. The same rafter node carries DES:* and BLD:* codes as part of an assembly stack and is also a node in the job DAG the scheduler compiles. Two natures, one node, no inheritance chain. That matches your interfaces point.

github.com/MLSystemsRI/ml-systems-public