There is a good chance I'll be wrong, however I believe you can only make the limit's worth, as refs are supposed to be unique for the lifetime of the VM's execution.

Well, if you need objs to click on, I'm sure you could do it by adding an obj as part of the global quest datum. Though there might be a way to avoid needing any object at all.

For your quest to kill 5 guys, all the text strings describing the quest would go under the global object, the kills variable would go into each individual quest log, the kills needed would go into the global, the update when mob is killed could be a procedure of either the quest or the quest log, and the complete quest procedure would go under the global quest.

Now, for this you're saving... 4 variables per quest by splitting it into two objects. (3 strings, and the kill number) I'll admit, that's not much (though if you multiply by 25 players, it becomes 100 multiply that by 20 quests and it's at least 2000), but I assume if your game revolves around quests, you are going to have more complicated quests. The more complicated the quest becomes, the more you can save by dividing it into two.

Not to mention that you can do some cool stuff with global quest datums that you wouldn't be able to do without them. For example, lets say you make a really hard quest. Perhaps you might save a list of the names of the players who have beaten the quest (or if it's an open ended quest, a high score listing). Something like that would be quite easy with a global quest datum. Granted, you would have to save the quest datum, but saving quest datums itself brings in a whole range of possibilities for features. Anyways, with such a wide assortment of quests (well, I sure hope you have a wide assortment, if it's just 50 item collection quests or something like that, it'd be lame) you never know what sort of features you're going to need. A dual datum system would give you the most options and the most flexibility in the long run.