Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production.

Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.

Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal.

So unless you have a ton of dependencies you wont notice much breakages from other teams.

A broken build is meant to be everybody helps fix it situation.

I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.

Tests breaking should be rare. And trunk based development requires the team working closely together. So working together isn't a adrupt thing.