> This might lead to a request with the query param name and the body param name…
Yes, and I fail to see why that'd be a problem. It might not be the most user-friendly way of designing an API, but that's in the realm of the designer. There's no problem on the HTTP level at all.
> … where the server has to decide how to handle it (Query over Body, Body over Query, both)
Who or what is "the server" here? One is a request parameter, the other is a field in the request body. If you as a designer of an API choose your URI and representation arrangement like this, it's also you who has to give an answer to this question.
It feels like we're stretching the boundaries of the scope of this list here, too. I try to avoid templating URIs of state transitions, especially if the client had to expand those templates using values from the representation the server just sent them. If that's the case, why not expand the URI on the server already?