Path Templating with multiple parameters allows for ambiguous parsing

Currently the support for path segments is ambiguous even in simple cases:

Consider:

paths:
  /{foo}:{bar}/update:
    post:
      summary: Example API with multiple parameters
      parameters:
        - name: foo
          in: path
          description: Foo
          required: true
          schema:
            type: string
        - name: bar
          in: path
          description: Bar
          required: true
          schema:
            type: string

If the URL /a:b:c/update is received, there are two possible parses which, as far as I can tell, the spec doesn't state which is correct.

• foo = a, bar = b:c
• foo = a:b, bar = c

This means that two different implementations may have different interpretations of how parameters map through.

Note, from an implementation perspective, this gets more challenging, as in order to parse the URL to work out which operation it is, you need to know the full structure of the path parameter, as that may break the ambiguity (e.g. if bar is an enum which can only take values c, or d, then the parse collapses into the second option).

Start with the path-template example in this issue and review the OpenAPI specification's rules for path parameters and operation matching. The work is done when the specification defines an unambiguous interpretation for URLs such as /a🅱️c/update, including how parameter constraints affect matching.