Thanks for building this, and for sticking with the thread as it got heated.
I want to name something before getting to a proposal. Pushback is not the enemy here, silence is. If nobody objected to a change, that would not be consensus, it would usually just be apathy. Every "why" thrown at this feature is exactly the kind of scrutiny that makes open source stronger than a closed product where one person's call is final. Linus' law puts it well: "given enough eyeballs, all bugs are shallow". The same holds for ux decisions, not just bugs, but only if disagreement stays welcome on both sides. Raising an objection is not an attack on the person who built the feature, and defending a decision is not dismissing the person who raised it. Everyone here is arguing because they want Flarum to be better, that is the whole reason a discussion like this exists at all.
With that in mind, here is a concrete way to close the actual gap instead of choosing between "always interrupt" and "never warn":
Instead of pushing a refresh banner into the user's face immediately, the server could send an additional response header on requests whenever a refresh is required (eg by sharing the manifest hash). Mithril's HTTP client middleware picks that header up and sets a flag (something like refreshOnNextAction or comparing against version hashes). Rather than surfacing anything right away, the app just remembers it. The next time Mithril would redraw, patch the DOM, or handle a click, it forces a full page refresh instead. That means an actively typing or reading user is never interrupted, but the next natural interaction (a nav click, opening a discussion, submitting a reply) picks up fresh assets automatically. No modal, no timing guesswork, no risk of wiping someone's draft.
