- Try to keep everything in one package
- Create a new 'major' release for Plone 5 only and keep the Plone 4 version support for a while or in maintenance/bugfix mode only
This only works if you can get rid of the old version support quick enough.
I have some client packages that work under Plone 4 and 5 but you REALLY have to know what you're doing. Especially the generic setup profile split was and is confusing, but also if you have 3rd party frontend libraries with js/css that you have to keep up to date.
But that's where the comparison ends because with Plone 4 -> 5 you still shared /duplicated the same (ZPT) templates and views in a server side system. From what I see now with Plone 6 headless the React frontend only needs the Content type definitions, permissions, behaviors etc server side. Everything else is not relevant and also not activated/triggered because you access/modify the data only through the REST API.
The bigger issue are secondary dependencies. If my current add'on uses Datagridfields, I'll have to pull in collective.z3cform.datagridfield on the server side, but that's adding complexit and posisble install issues without any of the frontend code in that package being necessary for headless.
Functional/design: all optional add'on configuration should always be exposed through Control panel Schema's stored in the configuration registry because Volto does already a good job to expose those panels automatically. Otherwise you have to tell people: noo but for this setting you have to go to the classic-UI website. No no no.
As @wesleybl writes 'it depends', the above are just other possible factors to add to the discussion, but it's rather tough to put objective weights to them.
My gut feeling to not have to clean up again in 2-3 years and have a 'clean cut' : same package name with major number in the semantic versioning.