What problem are you facing?

https://github.com/crossplane/crossplane/blob/056b421/contributing/specifications/xpkg.md

A Crossplane package is essentially a package.yaml stream of manifests inside an OCI image. The package manager lints this file before it installs the package. If it finds a kind of resource that it doesn't expect the package type to have, it returns an error and refuses to install the package. For example if it finds a Deployment or a CompositeResourceDefinition inside a Provider package, it'll return an error. It only expects a Provider to contain CustomResourceDefinition.

This means if Crossplane vN+1 adds a new Widget resource which can be packaged in a Configuration, any package with a Widget can't be installed on Crossplane vN or earlier. They'd see the Widget and refuse to install the package.

https://github.com/crossplane/crossplane/blob/056b421/design/one-pager-package-runtime-config.md

It also makes it difficult for third party controllers to extend the package manager. The package runtime design allows you to disable the built-in "deployment" package runtime and instead run your own controller that installs packages. The packages can still only have the types that the mainline Crossplane package manager expects to have in them though. For example you couldn't invent a new Widget resource and package it in a Configuration.

How could Crossplane help solve your problem?

I think the package manager should just ignore and log unknown resources, not error out and refuse to install the entire package. It should install everything it can.

This way a supplementary controller could handle installing the resources that were unknown to the package manager, if it's known to them.