Ok, I’m with you now 
Unfortunately, no, we can’t pass variables (i.e. the imported modules’ exports) here… the hot.accept() is basically saying, if any of the given modules (specified by their relative module ids) are updated, run the given function to accept the change.
This is part of the hmr-runtime; when a new bundle comes through after an update/save, we know which modules have been updated (by their ids), and then work out if there is code available to accept the change. Even with Webpack2 in ES modules mode, where you don’t need the extra require(), you still need to specify the modules with string names.
You can keep things more similar to how you had them before as long as you have a paired module.hot() clause which requires the next version of the module, and that setRoutes() can replace existing keys. e.g.
import Home from "/client/imports/pages/Home"
...
setRoutes( {
"/": { container: Home },
} )
if (modules.hot) {
modules.hot.accept('/client/imports/pages/Home', function() {
const NextHome = require('/client/imports/pages/Home');
setRoutes( {
"/": { container: NextHome }
} );
}
}
You should kind of consider the hot.accept() call itself to be outside the bounds of your regular app (just like import uses string module identifiers), and from inside the function you pass to hot.accept(), code works as usual.
That was kind of long but hope it makes things clearer.
Regarding point 2, yes; hot loading works per module (i.e. per file). But just like with import, you can do stuff with each modules exports indenpedently:
import { Container1, Container2 } from './containers.jsx';
if (module.hot)
module.hot.accept('./containers.jsx', function() {
const NextContainer1 = require('./containers.jsx').Container1;
const NextContainer2 = require('./containers.jsx').Container2;
// I guess if you really wanted to, doesn't cover changed closures
if (Container1.toString() !== NextContainer1.toString()) {
console.log('Container1 was updated');
}
});
But doing those kind of fine-grained comparisons isn’t very common. Don’t forget this is all just to save time during development… it’s generally ok if everything in the updated module flows to everything that imports that module.
Lastly, I hope it’s clear that I haven’t invented anything here… this is the same HMR pattern used by Webpack and Browserify. Oh and, I’m not 100% sure how Meteor’s client-side bundler will handle module id references that aren’t part of a require/import statement.
Happy to answer any more Qs
For me I quite like the combination of