A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.

If startup() fails, because you already have a server on the supplied port, for example, it seemingly hangs forever and prevents the rest of the code from executing. If I'm not mistaken, it used to return "[IP]:0" if it failed. Not 100% sure when this started though, it may have been when the -close parameter was implemented.

Also, startup() either starts new servers in whatever visibility mode the parent is set to, or to whatever the last DD instance was (not 100% sure which). This is understandable, but I think it would be better to always start new worlds in public mode. Or possibly, take a parameter for that setting, like it does for the safety mode.

I couldn't get this to happen in my tests. If the startup fails it does in fact return [ip]:0 for me. This happened whether DS was being hosted itself or not. If the DD instance failed to start, nothing happened.

We actually do have visibility parameters for startup(), though they are undocumented (and I think it makes sense to document them).

I can now verify this issue, but I'm afraid the solution is not readily apparent. It has to do with the way the slave server is being shutdown. The fact that this happens for unrecognized args further complicates the issue. I don't intend to let this go but I don't expect the fix to be in 494.