Ok, for those of you who worked with me at broadsword: doesn't this sound an awful lot like GPhi, circa 2005? It's got the "pools of components" (that would be gphi behaviour containers), "async update", that would be the behaviour container centric update, "implicit usage via existence", that would be the entity ID reference into behaviour container thing.
I'm reading it and I'm not seeing anything new apart from maybe the get component by interface implementation, but isn't that just as bad as dynamic casting in OO? Please correct me if I'm wrong, but surely you know what type of interface something has if you are updating its container in this system? If not, are you now doubly adding virtual overhead?
Also, in Dynamic Components (at least from this presentation) there's no mention of DLLs in conjunction with this stuff! That was one of the main selling points in GPHI, you don't need to know what a component/behaviour does, only that you could register a behaviour container and add the behaviour to your entity and let it get on with it.
But, and this is a big one, they implemented it. In a production game, they implemented the cool. GPHI never made it into any BS games, just an editor I used for animation adjustments and working with shaders, so they beat me there. The Ascendance project (which included the DB asset server framework, the crash proof editor, and game deployment tools) never got finished. Looking back, that was Jan 2005, just before first work on Snow Queen. That's a long time ago now.
One last thing too, at least mainstream thinking is catching up with what I've been doing. This should mean that when I've finished my tests and written my book on row oriented development, people's heads will be in the right place to fully appreciate it.