Probably outside of the scope for this PR, but another challenge I faced while using the SDK is some confusion in the generated type names.

For example, PrivateIpStackValue is missing from this code block, but I'm assuming it looks something like this:

type PrivateIpStackValue struct {
  V4 PrivateIpv4Stack
  V6 PrivateIpv6Stack
}

But in isolation, PrivateIpStackValue is a very generic name that doesn't communicate a whole lot. Something like PrivateIpDualStack would probably be better, and match its sibling variants name pattern (PrivateIpv4Stack and PrivateIpv6Stack).

The other variants also have a naming issue, with PrivateIpStackV4 being way too close to PrivateIpv4Stack. Maybe in this case we could add a *Variant suffix to make the variant struct more distinct and add an additional signal that this is a variant out of many options?

Putting it all together, these changes would make the generated code look something like this:

// Variant wrapper types (one per discriminator value)
type PrivateIpStackV4Variant struct {
    Value PrivateIpv4Stack `json:"value"`
}
func (PrivateIpStackV4Variant) isPrivateIpStackVariant() {}

type PrivateIpStackV6Variant struct {
    Value PrivateIpv6Stack `json:"value"`
}
func (PrivateIpStackV6Variant) isPrivateIpStackVariant() {}

type PrivateIpStackDualStackVariant struct {
    Value PrivateIpDualStack `json:"value"`
}
func (PrivateIpStackDualStackVariant) isPrivateIpStackVariant() {}

type PrivateIpDualStack struct {
  V4 PrivateIpv4Stack
  V6 PrivateIpv6Stack
}

But I'm not sure how much of this would be possible to auto-generate based on the spec alone.

We don't technically need it for our APIs, but would we need the YAML equivalent for feature completeness?

Not storing the discriminator field in the struct makes sense but the natural next question is how do we know what type the raw bytes are when unmarshalling. You answer that here but I think updating the wording to note that we explicitly read the discriminator from the JSON first before then deciding to read the rest of the JSON would be helpful. Perhaps this information is elsewhere already but I'm reading this linearly and making comments as I go.

Is this our desired end goal for such types or just a stopgap to maintain the current behavior today before we have time to revisit this?

This is a stopgap. I think it would be reasonable to change this to an interface type as well, but I didn't want to overcomplicate this initial PR. I'm down to explore that possibility here if you want, or maybe start a second PR branching off this one so we don't make this too hard to review.

Just to make sure I understand this part, would PrivateIpStack be an example of this? Where the same field (value) can be one of many types?

If so, would we be able to provide at least some helper methods for now so users don't have to marshal and unmarshal bytes themselves?