`oneOf` / `anyOf` usage with form-based content-type schema

Originally posted by @jacobjmarks in https://github.com/swagger-api/swagger-ui/issues/3803#issuecomment-965940166

I am having a similar issue here. See below an example spec in which I am attempting to describe a form which can accept one of two possible schemas:

openapi: 3.0.1
info:
  title: FooBar
  version: 1.0.0
paths:
  /foobar:
    post:
      summary: Summary
      requestBody:
        content:
          application/x-www-form-urlencoded:
            schema:
              oneOf:
              - type: object
                properties:
                  Foo:
                    type: string
              - type: object
                properties:
                  Bar:
                    type: string
      responses:
        default:
          description: Description

Please note that the same issue occurs when using a requestBody/content type of multipart/form-data

This endpoint should expect to receive a body of either Foo= or Bar=.
This schema causes the following Swagger UI interface to be rendered:

This is not correct. It is representing the form as a JSON payload and causes invalid requests to be sent to the endpoint in which the Swagger UI is encoding each character as a separate form value. E.g. sending a value of hi would result in the body 0=h&1=i.

This same issue occurs when using anyOf.

When using allOf, however, a correct representation is rendered as below:

Are there any updates here regarding the support for such oneOf and anyOf usage? Alternatively; am I incorrectly defining my schema in some way to achieve such usage?

Start with the supplied OpenAPI example and reproduce the form-based requestBody rendering for application/x-www-form-urlencoded and multipart/form-data using oneOf or anyOf. Compare it with the allOf example; done means the UI renders the form fields and sends Foo= or Bar= values rather than a JSON payload or character-indexed form values.