I have done a lot for this issue.

However, on reflection...

I think it's important that Composr provides tools that do predictable things, nothing too magical unless we can guarantee with a high likelihood that the magic is going to work reliably.
If magic is not reliable, it is better the user understands things as they work through a process using a collection of smaller tools that are themselves predictable.

Also, there's some duplication with other features, practically-speaking.

This issue was written after a lot of thought how we can make themeing easier in Composr, alongside many other issues full of ideas. The subset which has been implemented moves things forward a long way, even if not every individual part of it has happened I think overall every solvable issue has now been solved in v11.

"1) Edit an existing theme's seed (must be smart enough to only change images and CSS colours that matched the previous seed) (take from fix_partial_themewizard_css page, which is current a non-bundled addon)"

This is a magical thing. We cannot reliably see what is a customised user image vs something that came in from the Theme Wizard originally.
We have implemented (as a part of this issue) the ability to generate a Theme Wizard theme and download it immediately as a zip file. The user can use this to selectively upload replacement files for components of a theme, knowing they are only replacing parts they want to. Now that colour CSS is separated from the rest of the CSS, it's safe to just replace the colour CSS files.

"2) For each custom theme, provide a theme upgrading button which takes you to a theme upgrading screen"

All too magical. It's better the user studies and understands the theme process themselves. Or, doesn't have much of a custom theme as per in v11 how we've made the default theme itself far more configurable / made the Theme Wizard not override any CSS except colours.
We do have a theme upgrading capability in our upgrader, but it's currently disabled as upgrade code needs manually writing. Hopefully at some point someone can maintain this.

"1) Extend the template testing to specifically include ways of testing how overlays, and frames, look."

Done.

"a) Test that no localhost/local-domain/local-IP URLs are being referenced in templates"

This seems silly. Who is realistically going to make this kind of mistake in a template (manually edited)? Maybe in a page, in which case the Health Check system will find that.

"b) Test to see if the "reapply theme seed tool" tool needs re-running"

I decided not to implement this tool.

"c) Test to see if the "The version of Composr the theme was originally made from" option for any themes is outdated"

Better the user understands themselves through it.

"3) Third-party testing tool links (take code from theme_debug page, which is current a non-bundled addon)"

Actually this is better done as part of our testing platform (for developers). The tools in theme_debug were always developer-focused. And as it happens, almost everything was already in the testing platform too. I just moved a little bit into the css_file automated test.

"4) For each CSS have a validation link (for local validator and W3C validator)"

Done.

"5) For each screen preview have an HTML validation link (for local validator and W3C validator)"

Done.

"6) Find if conflicting theme images, e.g. foo.png and foo.jpg in the same directory. We have an automated test for this right now, so share the code."

Actually this is wrong. It is valid to have both foo.png and foo.jpg as the database provides a remapping layer and could map these to different theme images. It is correct only for us to do the test as a part of the developer testing platform.

"1) Ability for theme wizard to generate to a streamed zip file so that you may easily get files from a reference theme without adding a new theme to your live site to get at the files."

Done.

"Remove the theme_debug addon, as now everything from it will have been incorporated into other parts of Composr."

Done.