Opinion: Sooner or later there will be a need for versions that take in Adobe RGB and deal with it correctly (one that keeps things in Adobe RGB, others that convert to sRGB), and versions that produce 8 bit RGB (or Adobe RGB), it this tool is truly meant for "web publication".
Fully agree, although I have yet to test how much
improvement this will make compared to a 'round-trip' in 'assumed sRGB', where the original profile is reassigned to the image afterwards. After all, we are creating loads of totally new pixels, but they are (mostly, with some damage control) interpolated, and should stay close to the original real data. But you are correct that a fully color-managed (assuming there is an embedded profile in the image ) processing is preferred.
It is high on my ToDo list. Currently I'm not too happy with how PNG embedded profiles are treated by IM, JPG/JPEG seems okay, as is TIFF although they may still generate TAG warnings (probably to do with the version of the LIBTIFF library). I saw that Alan Gibson (snigbo) also has color management on his long ToDo list, perhaps because it's not all that simple to do (or just less urgent for him), given all possible situations one can encounter.
In photographic everyday practice we can be confronted with all sorts of profiles, such as device independent profiles (e.g. sRGB, ProPhoto RGB, Beta RGB), and device dependent profiles (output modality profiles, e.g. display, printer/paper), and even missing or incorrect profiles. And different operating systems may store the installed versions at different locations, as do some applications in yet other locations.
Currently, I save the originally embedded profile (if embedded) and reassign it afterwards, but some user interaction would be nice, as would the optional conversion to a different profile be. It will create a much larger script file though, due to the various scenarios one may need to tackle, but we/I could start with the basics.