Named User Events? - NOT using labels

Question

Why do user events require the event name be pulled from the label of the item wired to the create user event VI? I am looking to use user events which the name of the event may be wired separately to the create user event and register for event VIs.
If I have a data store with 1000 variant items in it. I want to create an "on change" event for each item in the data store. All of the items have the same data type.. a variant or some cluster of info.. and a different name. Other tasks can then watch for a specifc item to change by registering for an event with the same name and type. However, I certainly do not want to waste my time creating 1000 constants of the same type just to wire it to the create user event VI. (The actual names in this application may be built at runtime) I also do not want the tasks to have to watch for a common event that triggers whenever any item in the data store changes and then have to filter out what is relevant to the task. (this wastes resources)
Why can't the user event and register for event functions just use the type of the data and let the name be passed in separately like queues do??
Can NI provide me a simple patch to do this?

Answer 1

"is using only one event ok for you? You can generate this event everytime you write data into your buffer. If your event is of the type string, the you can send whatever data you need with the event (name, value, ...)."
This works, but I'm concerned about the performance hit / scalability of waking up every single task for no reason whenever anything changes just to realize it's of no interest and go back to sleep. Lets say there are 25 tasks. Each task is registered for one of 1000 items. Higher rate data may be changing which none of the tasks are interested in... Not very efficient to have one common event. 
"rather than pounding on an event structure to change it's shape, how about using "named queues"?
 Instead of the event in a loop you check the queue in a loop and if there is something there handle it like it was the event. You can set it up to either do it witha zero timeout (polling) or the loop can sit at the "Dequeue" until something is pusshed to the queue."
The current implementation is named queues. Yes this works, But what am I doing.... Using a queue to implement an event........ (why should I have to do this?) If you call a generate event and nobody is registered, nobody cares. You have to add logic to determine if you want to put an item on a queue in case nobody is listening so that you don't build up the queue..
"The type def is created as a constant via right-click menu on the wire coming from Create User Event. Just the label changed."
This is an interesting trick.. However, it still requires me to create a constant with x unique names. I guess I will have to do some testing to see if the events created in a loop are unique, but have the same name, or are truly the same event with unpredictabel results for creating many with the same name. (unless someone already knows the answer) ... If they are truly unique, but have the same name, I could use this for tasks that register for only a few items... Still rather cumbersome for tasks that need to register for many.