(Denny: you can consider this a reply to your question from last Friday)
SnakSerializer already has:
// TODO: we might want to include the data type of the property here as well
This was written nearly as year ago, some things have changed since then. In particular, it is now clear people want this, while there was no real interest in the question back then. Of at least equal importance is our change in defining what a DataType is and how these should be used. It started of as the enabler of having an SMWDataValue like interface, and now has been reduced to being a set of validation rules on top of a (Wikibase) DataValue. While in the former case there are many reasons not to have any logical dependency from DataModel on DataType, there are no such concerns with the later (and current) case. Given what we want a DataType to be (something that still needs to be reflected in its actual PHP definition) I think it makes more sense to have it inside DataModel then in its own component as it is now. It can then be linked to (logically or physically) from PropertySnak, or newly introduced containers, as we desire.
Putting DT ids in DVs remains problematic, for the same reasons as before. Luckily there are better alternatives then this approach.
Thought needs to be put into how to best move DT into DataModel, and how to best make use of it there. Before any concrete action is taken, we might want to have a close look at ValueValidators as well. This component has some open design issues, and will be introduced as a new dependency of DM if we move DTs there. Both of these concerns deserve their own discussions and are quite distinct from the current one (which is more about "what?" than "how?").