How does Kubernetes handle multiple API versions for the same resource?

In Kubernetes we can request resources using different API versions:

kubectl get roles.v1.rbac.authorization.k8s.io foo -n bar -oyaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: foo
  namespace: bar
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - secrets
  verbs:
  - create
  - get
  - watch
  - list
  - update

kubectl get roles.v1beta1.rbac.authorization.k8s.io foo -n bar -oyaml

Warning: rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: foo
  namespace: bar
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - secrets
  verbs:
  - create
  - get
  - watch
  - list
  - update

Would the API version used to create a resource have an impact on the resource stored in ETCD?
If a resource was stored when the newer API version (v1) did not exist yet, would this be a problem when the older API version (v1beta1) is removed?
Would upgrading to Kubernetes v1.22, which removes rbac.authorization.k8s.io/v1beta1, break already created/stored resources?
How are resource transformations between different API versions handled?

Solution

If a resource was stored when the newer API version (v1) did not exist yet, would this be a problem when the older API version (v1beta1) is removed?

Kubernetes supports a huge elastic deprecation system, which allows you to create, migrate and maintain API versions in time, however(jumping to your next question, you should sometimes manually upgrade API versions to up-to-date ones)

You can check Kubernetes Deprecation Policy guide, that is very important part of keeping cluster in work condition.

Main rules:

Rule #1: API elements may only be removed by incrementing the version of the API group.
Rule #2: API objects must be able to round-trip between API versions in a given release without information loss, with the exception of whole REST resources that do not exist in some versions.
Rule #3: An API version in a given track may not be deprecated until a new API version at least as stable is released.
Rule #4a: Other than the most recent API versions in each track, older API versions must be supported after their announced deprecation for a certain duration.
Rule #4b: The "preferred" API version and the "storage version" for a given group may not advance until after a release has been made that supports both the new version and the previous version

You can check also table that describes which API versions are supported in a series of subsequent releases.

Would upgrading to Kubernetes v1.22, which removes rbac.authorization.k8s.io/v1beta1, break already created/stored resources?

I think yes and you have to do some actions according to 1.22 RBAC deprecation resources

How are resource transformations between different API versions handled?

Check What to do