new rule for ambiguous path objects?

[baywet]

User story.
As an API producer, I want to ensure my description doesn't contain ambiguous path objects, so that my API consumers do not run into issues with tooling they might use with my description (code-gen, etc...).

Is your feature request related to a problem?

We've been seeing a lot of cases where paths are ambiguous in the description. A good example of that is trello which declares
/actions/{id}/{field} and /actions/{id}/board despite the fact that it's invalid according to the spec.

Describe the solution you'd like
The proposed rule would error on such instances, prompting API providers to better design their API. (in that case the fields parameter could slide to a sub path segment /actions/{id}/fields/{field} to be semantically more meaningful).

This rule would also implicitly validate colliding paths across levels like /{entity}/me and /books/{id}.

It could even validate against the usage of fragments in the path (although this could be a separate rule) like /foo/bar#baz.

Additional context
microsoft/kiota#3988

I'm happy to contribute this rule to the project, granted that I get some pointers.