Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main
This is the hardest part about trunk based development - changing your way of thinking. Everything needs to be decomposed into much smaller changes, and you need to think about the impact of each of them being deployed into production (since that will happen). New features should exist behind some kind of feature gating or dial-up capability, or a new API version with restricted access, etc.
That seems painful but it's less painful than merge hell or deploying a change with a massive delta to production and needing to roll it back and unpick what went wrong.
"before you work out all kinks and merge the staging branch back into main"
Working out all kinks on an isolated branch is very hard to do. You need to integrate to hear the screams of the team you never expected your change would affect. So your choice is to integrate commit by commit on trunk, or to wad it all up into a single waterfall release from your branch to trunk, and then spend hours/days bisecting to find which commit caused the screams.
As jozzas said, feature flags enable your code to safely lurk on trunk before it's functional.
