[Andreas]

Originally Posted by merk

1) The plugin that accesses a hook should do the standard thing it does to access the datastore item. (IIRC, $vbulletin->name) - however, it may need to be unserialized. I dont see an issue with unserializing in global_start.

Well, the Item won't be available as $vbulletin->name if it wasn't in $specialtemplates before calling global.php.
And as Plugins are being loaded out of the Datastore it can't be added through Hooks. That's the whole point of this Thread:
We've got a "Chicken and Egg" Problem here
As I already said, your suggestion works fin - when the default Datastore Class (Database) is being used.
But what's your solution when using other Datastore Classes?

For the other datastore types, (because there are no queries involved for other types) it should be as simple as querying the datastore table once (an extra query for one page load) to load the datastore item into the other types' storage method.

Ah, now there we go.
Sure, that would be possible - with the dabwack of having an additional Query for every Pageload.
And that's what the discusssion here is all about: Which approach adds the smallest Overhead possible?

There is an issue with this in that if the datastore item updates in the datastore, the product will have to deal with it gracefully and update the datastore properly, calling the datastore methods that do the magic they do.

The Datastore Classes will take care of Updates, that's not a Problem.