After analysis of the many Wiki ThreadMess, there has become a clarity that allows some order to be placed on the notion of "the Object".

There are two poles to the Object landscape within ObjectOrientedProgramming, both of which misinform the theorizer and ProgrammerWhoWantsToUnderstand.

* In the CeePlusPlus way (named since BjarneStroustrup came up with the example, not because it is typical), one has been trained by the idea of modelling computer-world artifacts (cf. CircleAndEllipseProblem). As such, one has been trained by the SimulatedWorld object mindset. This SimulatedWorld mindset, encompasses games, but I argue, no one models such objects in practice. So this model fails to ''generalize''.

* In the Python way (post v2.2 type/class unification), one has been trained by the EverythingIsAnObject mindset, where there is no attempt at a SimulatedWorld, there is only a pure abstract Object from which every other object derives. This conceptualization has failed to create inter-operability, one of the promises of OOP (see ObjectOrientedRefactored), because by being so abstract there is no common point in which people actually want to operate from.

In between these two poles or ''extrema'', and since ultimately AllDataRelatesToOtherData, there is proposed the possibility of a UnifiedDataModel encompassing most of what programmers ''*actually*'' do, when they aren't thinking of abstract theoretical ToyProblem''''''s. See DataEcosystem.

This is not to be confused, by the way, with the mathematical idea of TypeSystem''''''s, which is also in between these two extremes, but in the ''opposite'' direction -- into the Platonic realm of mathematics. This unconscious conflation has confused and unintentionally alienated the ComputerScientists from the ComputerProgrammers who tend to employ the same terminology for different purposes. Despite the two sharing a mathematical commonality, one deals with logic gates and BooleanLogic while the other deals with Symbols.