The 'Bundlor-Comment-1..n' solution is indeed not the prettiest.
The multiple Comment: is probably also not practical (at least which comment ends up in the generated manifest?) It feels a bit 'hackish' like the first.
The latter would be the nicest. I've got no emotional attachment to the manifest spec. It's a horrible format. So the two formats solution would have my preference.
XML is also not the nicest format for a user, but it could also serve pretty well and it scales better than property files (should one ever want nesting, and an XSD gets you syntax checks and completion for free). At least I'm would also be delighted with an include mechanism. (adding the same bit of imports for some specific AOP constructs gets a bit stale after the first few bundles)
The JSON format that is used in some spring dm server config files btw reads better than XML. But no XSD's etc. there.
I personally use the plain text mode to edit manifests/template.mf/test.mf etc, so I can live without most of the UI around manifests/templates. The UI bits only slow down, since I have to click through to the manifest tab. (I personally prefer plain text with good completion, over a slow point click interface. With plain text I can copy paste a class not found exception/or the likes from the problem view into the template then strip out the error messages, regenerate, and be on my merry way. I must say that I've been using spring dm server and sts tooling since it came out and I think I've never ever used the point click UI to edit a manifest/template). Assuming of course that STS can pick up the new format and generate a manifest from it, else the use would become less again.