The dependencies between the exported resources is not obvious from their metadata since each is independently exported. In order to help with their export, their annotations could be enhanced to include a category or a level.
The order of restoring the Kubernetes resources at another point is also not known. When databases were backed up and restored, the order of creation was known from their schema. However, in this case the Kubernetes resources are independently exported and imported. Even if it is a custom resource, all that needs to be imported first is their custom resource definition.
A Custom resource application can include other definitions so there is definitely a cascading order of creation involved. This order is already determined in the charts that were used to deploy the product. The export order can be any order but the import order has to be the same as what the charts had described at deployment time.
The order of export and import do not have to be reverse of each other but it certainly helps to verify the order offline.  The attributes such as creationTimestamp, deletionTimestamp, uid and even finalizers can be removed prior to import.
A command like “kubect get all -n <user-namespace> -o yaml > user-namespace-resources.yaml” will infact determine the order appropriately which can then be directly supplied to the “kubectl create -f user-namespace-resources.yaml” as long as interfering attributes have been removed.
These won’t export custom resource definitions or the resources that can be fetched with “kubectl api-resources" nor will it setup the persistent volumes and external services that are represented via service brokers within the Kubernetes clusters. Those are assumed to be ready before the import begins.