Currently there is no information in the docs about how a plugin might migrate to support flat configs.

For example - one would need to migrate shared configs to the new format - but what does that look like? I know that theplugins key needs to change its form - butthe existing docs still use the old form.

How should a plugin go about supporting both flat and classic configs? What's the best-practice for doing this?
For exampleeslint-plugin-react exportsconfigs from the package root in the classic form, and provides imports for each config in the flat form (require('eslint-plugin-react/configs/recommended')). Is this the "best practice" way of doing it? Is there another way?

What about things likelanguageOptions - how can you support both?

Is there tooling to do this automatically so that plugins don't have to all implement the same copy pasted logic of "extend the classic config and rename somethings"?

I guess what I'm saying is that the user story for flat configs is well documented and planned out - but it feels like the developer story is lacking right now which makes it hard for plugins to build support.
We have users asking for it so they don't need the compat layers - but without clear guidance and best practices we don't want to take the step lest we do it wrong and have to release a new major version to undo a change.