I’ll just pitch in one (not so) brief thought here, and I don’t mean to be all down on your idea or anything, but just consider this for a moment:
Active Record is a pattern designed specifically to address the problem of object-relational impedance mismatch.
Query operations on relational databases are abstracted away to some extend, but they are never fully or perfectly abstracted away, because no matter how you twist and turn things, objects in-memory are a graph, and tables are two-dimensional matrices.
Some object-relational mappers go to excess to ensure that relational database "smells" are fully abstracted away, such as Hibernate and Doctrine - and still, with these massive codebases, you invariably run into situations where the abstractions can only get you 99% of the way.
Yii’s lightweight AR approach is of a different school - it’s not at all hiding the fact that the underlying storage is a relational database, we are openly doing bits of query syntax, joins, primary and multiple keys, table/column schema reflection, etc., etc.
Personally, when working with a relational database, I favor Yii’s approach - attempts to abstract away the fact that you’re working with a relational database, lead to overly complicated abstractions that take years to master, and many more years to implement and perfect. Hibernate was started in 2001, and they’re still struggling. In my opinion, they’re swimming against the stream.
My point is that, unless you’re willing to go to great lengths to fully abstract away all aspects of relational databases, your abstraction is always going to leave a scent of relational storage.
But more importantly, consider this: even if you did achieve the perfect abstraction, and there was no trace left of relational storage in user code - how much sense would it make for you to switch the storage provider to something like a graph database?
Most graph databases (and certainly document databases and key/value stores) still have a limited (if any) ability to perform projection-queries across multiple entity-types. If the storage-layer for you favorite key/value-store results in AR throwing exceptions at you when you issue a with() statement, the most you’ve achieved is a similarity between storage-layers - not compatibility.
For another, if you had a graph database, which was a perfect fit for your object-graphs to begin with, why would you want an AR-style abstraction on top of it? This would most likely make it less convenient, not more, as object-storage is already a near-perfect fit for object-graphs.
I think it’s better to accept the fact that new storage paradigms are not compatible with our old way of thinking, and that this is in fact a good thing, because the old way of thinking was not very sound to begin with. Just my personal opinion.
Food for thought, that’s all