After I investigated a bit further on #372 and #213 I found that my PR #366 is not a real solution:

• it guarantees that members are destroyed BUT now Templates will have no DOMRange in their onDestroyed callback available, which is basically the same issue as in Blaze.remove() destroys DOM before calling onDestroyed() #372
• the root cause is, that a package I used swallowed up an error from onDestroyed which in the end prevented the DOMRange to be removed
• the package itself still surrounded things in a try/catch and monkey-patch removed the view using Blaze.remove
• however when next time visting the template I get DOMRange must be attached
• the whole issue can be fixed by surrounding callbacks (onCreated, onDestroyed, onRendered) with a try/catch that does not bubble up the error but reports it to the Blaze console:

old:

Blaze._fireCallbacks = function (view, which) {
  Blaze._withCurrentView(view, function () {
    Tracker.nonreactive(function fireCallbacks() {
      var cbs = view._callbacks[which];
      for (var i = 0, N = (cbs && cbs.length); i < N; i++)
        cbs[i] && cbs[i].call(view);
    });
  });
};

new:

Blaze._fireCallbacks = function (view, which) {
  Blaze._withCurrentView(view, function () {
    Tracker.nonreactive(function fireCallbacks() {
      var cbs = view._callbacks[which];
      for (var i = 0, N = (cbs && cbs.length); i < N; i++) {
        const cb = cbs[i];
        if (cb) {
          try {
            cb.call(view);
          } catch (e) {
            Blaze._reportException(e, `expection in callback ${which}`)
          }
        }
      }
    });
  });
};

This together with #374 should be the right fix for issues relateded to #372 and #213

Note: I moved too quick with #366 so I thought we discuss this first, before moving on and creating a PR, since I don't like to add PRs that have to be reverted later on. Any thoughts on this @StorytellerCZ @harryadel