It’s great to see movement on this already, these are all positive changes. I respect the minimum viable design approach, and I think with a couple more tweaks you can turn the above into a minimum delightful design!
Package testing is WAY cheaper than app testing in terms of memory and CPU and you can see this in Velocity based frameworks (even ones that use just one mirror). The running of 2 meteor apps means a user would likely run either in normal mode, or in test mode but not both. I agree it’s not a deal breaker, but consider this quick win to improve the user experience when running multiple Meteor apps for testing purposes:
When a user runs meteor test and then runs meteor, the latter would detect the existing running instance and starts a node process on the main.js but this time without the isTest flag set. Perhaps something solution like the Autoupdate Watcher would work here.
The result is a nicer developer experience, and this is one of the major pains-in-the-ass of meteor testing solved 