What do you want to happen?

A plugin base which would be responsible to scaffold what is common for any kind of plugin no matter the language and what be integrated with KB and use it's as a consumer. ( basically, it is the hack and config directory since the PROJECT file is scaffold by the CLI )

It would allow the community to create any language/type plugin using the same base/config defined by KB in order to ensure its compatibility and maintainability see operator-framework/operator-sdk#2745 the requirements/problems that also could be addressed with:

• Make SDK use the real plugin system instead of having to do “hacky” wrappers around the go.kubebuilder.io plugin. To SDK Helm/Ansible plugins it would actually mean only implement what which is specifically for its types which means that SDK project would no longer need to copy and paste the config directory boilerplates from kubebuilder in order to do the same.
• It could allow we init hybrid operators such as; layout: config/v1,helm/v1,go/v3 which would have the init scaffold of all plugins. See: Support hybrid operators operator-framework/operator-sdk#670
• Solve the concerns issues raised in the WIP [SDK] - Proposal to split Helm/Ansible on their repos operator-framework/enhancements#44 regarding the risks of the language plugins deviated too much from the upstream base and to keep they maintainable.

Is there currently another issue associated with this?

This issue would be a follow up of #1991 and #1941

backwords compatibility

In order to ensure the backwords compatibility if we call the init command by informing only a plugin that is not the base config, the CLI needs to scaffold the base + the config as it is done currently. E.g operator-sdk init --plugins=helm/v2 will scaffold the base+helm