A `null` `default` is incorrectly deserialized as `JsonValue` of kind string with value of "null" from YAML and there is no way to distinguish between an `undefined` `default` value and a `null` `default` value.

[jkporter]

Describe the bug
When deserializing default value from a YAML document and that value is null it is converted to a JsonValue of kind string with the value of "null" making it ambiguous. In actuality it should result in a null JsonNode. Furthermore, there is no way to distinguish between an unset default value and a default value of null since JsonNode cannot represent a JSON null value beyond being null itself.

OpenApi File To Reproduce
https://api.ynab.com/papi/open_api_spec.yaml

Expected behavior
Default would return null instead of a JsonValue of kind string when deserializing from YAML and an additional property should be added such as DefaultIsNull. Alternatively, the type for the Default property should perhaps be changed to JsonElement with correct type deserialization.

Screenshots/Code Snippets
Currently have this workaround which tries to guess whether Default should be considered a null value or a string of "null".

var valueKind = property.Default.GetValueKind();
if (valueKind is JsonValueKind.String
    && property.Default.GetValue<string>() == "null"
    && property.Type is not null
    && (!property.Type.Value.HasFlag(JsonSchemaType.String) || property.Type.Value.HasFlag(JsonSchemaType.Null)))
    valueKind = JsonValueKind.Null;

[baywet]

Hi @jkporter
Thank you for using the SDK and for reaching out.

I've implemented a fix for the YAML deserialization in #2559.

For the "assigning null from the object model, and wanting serialized null values" problem, it's going to be longer to fix because of a design issue, which would require a source breaking change.
Essentially, system.text.json DOES NOT provide a JsonNode/Value for "null", and they probably never will add one as they want a single primitive for null (the other one being dotnet null). dotnet/runtime#68128
Because of that, and the fact that default, example, and value use JsonNode, it's semantically impossible for you as a consumer to "tell the difference" between "the value was never assigned, or reset" and "the value should be null in the serialized representation".

The proper solution to that, which is source breaking and will require a new major version, would be to:

1. Define a new type e.g. "JsonNodeWrapper" with either a flag for null values, or a subtype.
2. Update all properties that use JsonNode in the object model to use that new type.
3. Implement implicit conversion from JsonNode to that type (so the API for consumers stays roughly the same)
4. Update the deserialization code to special case reading null.

[C0nquistadore]

This is really unfortunate. To be honest, this is already a breaking change, because it worked perfectly fine in v1, at least the scenario I described in #2554. So this means, this blocks us from upgrading from v1 to v2 and instead we have to wait for the next major version, whenever that will be.