I like a clear handover. People need to know when they can start their work and what they're working with.
But handing something over doesn't mean every decision behind it is finished. It doesn't mean your job is done.
I'm thinking about the booking calendar again. During development, if the dev had discovered that finding the next available appointment took far too many steps with a keyboard, what should they have done?
They could have tried to solve it by themselves. They'd decide some experience that perhaps would have worked. Perhaps not.
They could have instead sent the whole design back. Then the designer would have been pulled away from what they were doing to rework something they thought was finished already.
Neither of these two options feels especially useful to me, especially when a short conversation might help the team choose a simpler approach.
That's why I think the people behind the earlier decisions need to stay reachable throughout the process, even after handover. If anything looks wrong later, the designer can explain what they considered, they can clarify whether patients usually need the earliest appointment or a particular date and the developer can show what the current approach makes difficult.
And most importantly, this can happen in such a way as to not require everyone be present in every meeting. The process just needs a way to reopen a question without treating it as a failed handover.
There are limits to this of course. Constantly reopening settled decisions makes delivery difficult too. I'd look for new information that affects someone's ability to complete the task, rather than another preference about how the screen should look.
The bottom line is that unresolved questions become expensive when people work around them in isolation.
A clear handover should let the next person move forward with confidence, including the confidence to come back when what they discover changes the decision.