This answer is a frame challenge.

But I think there is some semantic benefit in having exactly one path for all updates of a entity, in different ways.

Perhaps you are not aware that what you are describing is a core design element of SOAP/WSDL based services which was a large part of the problems with the web services built upon them. When you do something like this, you are ignoring the features of HTTP designed to solve this problem, hence your struggle.

Routing requests using HTTP features designed for that purpose will make your goals much easier to achieve and your solution more easily understood and supported. Unless you can identify some specific benefit of this that cannot be achieved using HTTP features as intended, I don't see any good reason to do this. The one caveat would be if someone had decided to do this in the past and you were required to make a backwards compatible solution. But in this case, you would be the person potentially creating that problem for someone in the future, if I understand correctly.

One of the more serious issues with this is that you may make your solution significantly more difficult to secure. For example, if you used a separate path for your admin operations, firewall rules can easily be setup to restrict access to that endpoint from only approved IP addresses/ranges. If you use a single endpoint that solution doesn't work, and you will need something that can inspect the contents of the message and writing custom rules. The risks of an error resulting in a vulnerability are much higher when you customize your security solutions.

This answer is a frame challenge.

But I think there is some semantic benefit in having exactly one path for all updates of a entity, in different ways.

Perhaps you are not aware that what you are describing is a core design element of SOAP/WSDL based services which was a large part of the problems with the web services built upon them. When you do something like this, you are ignoring the features of HTTP designed to solve this problem, hence your struggle.

Routing requests using HTTP features designed for that purpose will make your goals much easier to achieve and your solution more easily understood and supported. Unless you can identify some specific benefit of this that cannot be achieved using HTTP features as intended, I don't see any good reason to do this. The one caveat would be if someone had decided to do this in the past and you were required to make a backwards compatible solution. But in this case, you would be the person potentially creating that problem for someone in the future, if I understand correctly.

One of the more serious issues with this is that you may make your solution significantly more difficult to secure. For example, if you used a separate path for your admin operations, firewall rules can easily be setup to restrict access to that endpoint from only approved IP addresses/ranges. If you use a single endpoint that solution doesn't work, and you will need something that can inspect the contents of the message and write custom rules. The risks of an error resulting in a vulnerability are much higher when you customize your security solutions.