AOM

I think that AOMS is a terrific architectural style!  I've developed one system in the past that was a simple, but near textbook instance of such a style.  The decision to build the system this way was based upon the reality that due to politics and indecisiveness of the client (don't get me started!), the schema for a traditional data management solution couldn't be decided totally up front--the requirements would shift drastically from day to day.  I experienced the true power of such an architecture when I was able to update the domain model, and along with the automatic web UI generation that I had in place, have an updated application ready for review within 15 minutes of the conclusion of the conference call detailing said changes.  I'm also currently developing a much larger system, which exhibits some much more advanced concepts from this architectural style, designed to allow the system to be re-configured at runtime to account for changes to rules and data both in the existing sub-domains, but also to extend to (similar), but yet to be thought of domains.

One of my primary concerns as systems like these grow is performance.  I'm using a relational database backend, which has been optimized by the vendor to provide very efficient operations on sets of data defined in database schemas.  When you model the domain at a higher level of abstraction, you break a great deal of the anticipated locality of data, and spread out reads across a much larger set of rows.  Time will tell what type of optimizations will be necessary to keep a system like this performant as it scales to a large number of concurrent users.

For an Object to change its TypeObject, it may be necessary for some translation logic to occur. You can imagine a scenario where such a conversion may fail--if the destination TypeObject has a different set of properties, some required properties may need to be provided, and existing properties may be lost if they don't adhere to the specifications.  Additionally, there may be business rules relating the existence of various objects, so perhaps the lack of existence of the source object would be a problem...perhaps there are cardinality constraints on the destination object, and even more confusing, what if there were validation logic that could only be executed at a certain point in time...perhaps a function that depends on the current date/time.  In this scenario I don't know that you can say in the general case, an Object CAN change its TypeObject.  In absence of other constraints, sure, its just a mapping of properties, but the real power of such an architecture is to be able to model complex rules, and not know about these rules at compile time.

Versioning in an AOM architecture comes in two flavors--data versioning and model versioning.  Data versioning can be handled by a common set of functionality across all objects by storing updates as new values, with associated timestamps, and upon retrieval, always retrieving the most recent data.  Model versioning can be achieved through translation of "V1" domain objects to "V2" domain objects, or simply by allowing these two different versions of the same type of object to exist in the system at the same time.

The "explosion of new types" won't happen at the code level, due to the nature of modeling the domain in data, but it can happen in the model itself.  Controlling the growth of the model is as simple as controlling the users who are allowed to change the model, providing adequate training to these users so that they implement domain entities in the desired manner, and ensuring that appropriate communications channels are available, so that functionality isn't duplicated across users and/or time.