Arazzo-Specification/examples/1.0.0 /FAPI-PAR.openapi.yaml is invalid or misleading

This example is invalid (or at the very least substantially misleading) and (if I am reading it correctly) should not be publicly visible in our repository in its current form. At minimum, the following excerpted bits are illegal as Content-Type SHALL be ignored as a parameter. The configuration below requires an application/json body, but the invalid header parameter seems to try to require a form-urlencoded body.

This just does not work, and we do not want give users the impression that it does.

  /as/par.oauth2:
    post:
      parameters:
        - name: Content-Type
          in: header
          schema:
            type: string
            default: application/x-www-form-urlencoded
            enum:
              - application/x-www-form-urlencoded
          required: true
      requestBody:
        description: |
          parameters that comprise an authorization request are sent directly to the 
          pushed authorization request endpoint in the request body

          [PAR Request](https://tools.ietf.org/html/draft-ietf-oauth-par-07#section-2.1)    
        required: true
        content:
            application/json:
              ...

This also does not make sense to me, although that may be on my end as I feel like I must be missing some things:

      responses:
        302:
          description: |
            Redirect to defined redirect uri with the authorization code as a standard OIDC response. 

            >**https://**_{your app redirect_uri}_
            
            >**?code=**_{Arbirary String}_

            >**&state=**_{state value from authorization request}_

            >**&iss=**_https://api.example.com_
          links:
            Authorization_Response:
              description: >
                The `code` value returned in the response MUST be used as
                the `request_uri` input parameter in `GET /as/authorize.oauth2` when 
                using the authorization code flow, before it expires.
              operationId: Token
              parameters:
                code: '$response.path#/code'

I'm not actually sure what is being attempted. The description indicates that code is a query parameter in the redirect URI, but the Authorization_Response Link Object seems to try to pick it from the response path (which... is that a thing? how does that work?) and map it to the code parameter for the Token operation, while saying that it needs ti be passed in request_uri?

Plus, AFAICT, all of this is coming back in the 302 redirect's Location header, but nothing in the link is attempting to access that. And we don't have the ability to parse that with runtime expressions anyway (although it's possible I'm wrong there?)

There might be other issues here, this is just what I've noticed at a quick glance. I'm also curious as to why this is using OAS 3.0 when it needs mutualTLS which is available in OAS 3.1+, but that's less of a concern as it's not misleading, just regrettably outdated.