Not at all. The main difference is that the user cannot ask for a query before they are available.
User can only access the 'results' from the parameter passed into the callback.
I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want.
Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use.
The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list…. They are individually addressed in the callback, the user can put the result it whatever data structure it want….
Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread