This syntax has a bug where it relies on having html5-tokenizer on the client, code which was written for the server (and uses Function.bind, defineGetter, etc.).
The plan is to deprecate/remove this syntax anyway, i.e. not allow
you to say `<x {{{attrs}}}>` and then have `attrs` evaluate to a string like
'key1="value1" key2="value2"' at runtime. Constructing these strings is error-prone and likely to be insecure.
Instead, you'll have your choice of double-stache in an attribute value, with or without quotes (`<a b={{c}}>`, or `<a b="{{c}} {{d}}"`, or even `<a b={{c}}-{{d}}>`), or double-stache at the top level of a tag, as in `<a {{b}}>`, in which case `b` must be either a dictionary of attribute names and values or a string containing at most a single attribute name (e.g. "selected" or "").
Instead of a general client-side sub de-duping mechanism (which mostly existed
for the sake of autosubscribe, and causes issues with server-driven
unsubscribes), make Meteor.subscribe explicitly aware of reactivity.
Expose an "invalidated" flag on Meteor.deps.Context.
Guarantee that invalidation callbacks from different contexts will not be
interleaved at flush time. This has the implication that if you do
context1.onInvalidate(function () {
context2.invalidate();
});
and this is the only way to invalidate context2, then context2's invalidation
callbacks will not be called until after *ALL* of context1's callbacks are
called. This allows us to be sure that the "unsubscribe, unless autorun tried to
re-create an identical sub" logic runs after the autorun function is rerun.
