To recap our call, and previous discussions

There shouldn't be any field/state for nullability on the OpenAPISchema model, only in the deserialization phases.
We shouldn't be "moving schemas arounds" (except for v2, because that behaviour has been here for 10+ years at this point).

OpenAPI 3.1/3.2

serialization and deserialization should be symmetrical, serialize type null as part of the type property, array or single.

OpenAPI v3.0

serialization

Serialize type null (no other types) as enum null because nullable true by itself is ignored and the resulting schema would validate anything.
Serialize type null + something as type something, nullable true

deserialization

Deserialize type something to something
Deserialized nullable true to a marker in the metadata dictionary.

Once both properties are deserialized:

• if nullable true is by itself, drop it, because it only applies when a type is also provided
• if nullable true is with a type something, add null to the type array

Swagger 2.0

serialization

always serialize type null (with or without something else) as x-nullable: true. That's because :

• one/anyOf is not supported by this version of the standard
• we're already picking the first one/anyOf entry, that bechaviour has been here for a long time, we shouldn't change it
• enum null can't be composed, is therefore useless, so we should diverge from OpenAPI 3.0 behaviour.

Deserialization

Do the same mark and resolve behaviour as V3.0 for consistency, but for the x-nullable extension.