Theme-specific admin settings dead

I guess that I'm the only one who ever implemented theme-specific settings in a 5.x theme(?)

As seemingly supported (see system_theme_settings()), I implemented phptemplate_settings() form subpart definition in my_theme/template.php, to add a theme-specific fieldset to the theme-configuration page (admin/build/themes/settings/my_theme), so that additional settings are presented on that page (background-image switch in my case), and may be then retrieved via theme_get_setting('setting_name'); in the actual theme (page.tpl.php).

I ran into three bugs:

- The phptemplate_settings() definition was NEVER invoked, so this whole feature simply didn't work. System module attempts to do it, but it never get past the function_exists() check, because the theme is not loaded yet (!) meanwhile. Adding an init_theme() call just before that solved this problem for me.

I know that it won't work for other themes than the currently active one, but fixing the whole theme system (being unable to include more than one phptemplate theme at a time) is definitely out of scope, and impossible on a stable branch (5.x), or post-beta (6.x). My patch makes it work for the currently active theme, which is the best we can do now (adjusting settings for a theme other than currently active is a bit of edge case; also consider that previously it didn't work at all, so it probably affects only just my theme and my site now - another issue may be opened for 7.x if the problem still persists (not checked yet)).

- When I fixed the above, the fieldset appeared with the title "Engine specific settings". But there is no such a thing like engine specific settings (unless some other engine implements this differently); this is coming from the theme. So I can't see why we were doing any difference between phptemplate and old-fashioned themes - now simplified. Also the engine name 'phptemplate' was shown instead of theme name in a message.

If you're about to say, that I shouldn't change the behavior of UI messages on a stable branch in any way, then I must remind you again, that no-one have ever seen that message probably, because the whole feature didn't work at all.

- Observing the theme settings in database, I see that two unrelated form elements got stored accidentally in there: 'form_token' and 'op'.

Attaching my patch for 5.x now. I know that common workflow is to patch HEAD first, but currently I fixed it on 5.x for my production site, so why not submit the patch today. I'm going to check (and fix, if necessary) on 6.x-dev tomorrow.