Which Backbone.Events pattern keeps model-change alerts useful without flooding the UI?

I'm designing an alert layer for a Backbone.js application where several models and collections fire change events rapidly (live form validation plus polling sync). I want users to see meaningful notifications without a toast appearing on every keystroke or every poll cycle.

Two documented building blocks seem relevant: a central dispatcher built with _.extend({}, Backbone.Events) so alerts are decoupled from individual models, and wrapping handlers with _.throttle or _.debounce so bursts collapse into one notification. Assume Backbone 1.x with Underscore available.

My uncertainty is how these compose. If I throttle at each model listener, different models still alert independently and the UI can flood. If I throttle only at the dispatcher's single alert event, a slow-but-steady stream of distinct issues may get swallowed, and an aggressively long interval could hide legitimate rapid validation feedback.

Which layer should own the rate-limiting: per-model listeners, the central dispatcher, or both with different intervals?

Is there a conventional way to distinguish 'important, alert immediately' events from 'noisy, coalesce these' events through one dispatcher without string-matching event names everywhere?

Are there known pitfalls with off() unsubscription when the subscribed handler is a throttled wrapper rather than the original function?