Pathological CRD generation when struct names clash

[Miles-Garnsey]

We have two packages/groups defined in our APIs directory. There is a struct with the same name in each; one of which is intended to generate a CRD, and one of which is just a field within another CRD.

Example:

// in apis/ourapp/v1beta2/ourresource1_types.go

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:storageversion
// +kubebuilder:resource:path=missioncontrolclusters,shortName=mccluster;mcclusters

type Bar struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   BarSpec   `json:"spec,omitempty"`
	Status BarStatus `json:"status,omitempty"`
}

type BarSpec {
...
Foo *Foo `json:"foo,omitempty"`
...
}

type Foo struct {
...
}

// in apis/ourapp/v1alpha1/ourresource2_types.go

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:storageversion
// +versionName=v1alpha1
// +kubebuilder:printcolumn:name="Error",type=string,JSONPath=".status.error",description="Latest reconcile error"

type Foo struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

	Spec   FooSpec   `json:"spec,omitempty"`
	Status FooStatus `json:"status,omitempty"`
}

When the CRDs get generated, we're seeing both a v1alpha1 and v1beta2 resource version being created within the CRD.

This is incorrect and results in the spec of the Foo being deleted due to some sort of conversion webhook mechanics.

Is there a documented constraint that a struct with the same name as a kubebuilder object root cannot exist in another API version/package?

[sbueringer]

Is there a documented constraint that a struct with the same name as a kubebuilder object root cannot exist in another API version/package?

Not that I'm aware of. Sounds like a bug