Couldn't find this anywhere so creating a issue for it.
As mentioned by Douglas Crockford in a recent YUI Theater post: Loopage 38:30 - 39:42, require() should be non blocking.
I have tried to suggest a syntax beneath with performance in mind. Other then that; object types, function names and param names are just suggestions and is up for debate.

Possible syntax:

/** Non-blocking require, aka Asynchronous Module loading
 *
 * @param string|array modules
 * @param function callBack
 * @param object settings Placeholder, can in the future specify timeout both for local and remote(also very tbd) loading.
 * [IF POSSIBLE @return int Return identifier to be able to kill the loading later like setInterval/siteTimeOut
 */
require2( modules, function callBack( null|Error err, object modules ){}[, {} ]);

Example use:

require2( array( 'http', 'sys' ), function( err, modules ){
    // given it's parallel async nature, modules is an object hash, and not a in order array
    var http = modules.http, sys = modules.sys;
    // do something..
});

1. In the first round something like the code / syntax shown above (note: in the end there should only be one require function, and it should be non-blocking imho. Just calling it require2 for convenience).

2. (optional) It should use the same require.paths system as require, with one distinct difference, it should lookup list of modules and cache on first call to not have to iterate the list on each call. This cache should be cleared on changes to .paths, something that might imply that it should use functions to add / remove instead of exposing it as writeable, or to not break the syntax, enforce usage of a require2.clearCache() or similar.
   This cache should probably be disabled in debug mode (as mentioned in node.js's TODO)

   2.1 (possibility) require.paths could be read in reverse order to allow an 'override' system where you can override modules to extend them to your needs, but such a feature should probably be disabled by default and enabled with a 'settings' param, e.g.: { 'reverse_paths': true }

3. For later probably, but should be mentioned: module dependency support
   This will be needed when require stops being synchronous, and should hence be handled by the loader.
   We don't have oversight like YUI has for use(), and neither do we want to hard code dependencies in our user code for external modules we use, when the module can be updated at any time and at some point people will probably use so many it would just be ridiculous to have to maintain a hash of dependencies your self. So modules should define this them self but in a way so that the loader can know about it before it loads and executes the module (so not like YUI.add does).
   Could reuse package.json for this or something similar, at least a extend able json format, and let cache mentioned in 2. handle loading this for all modules on first use.

Notes:

• Should probably sync with ES-Harmon Modules "Asynchronous Module Importing Extension" de-sugared syntax proposal
• And the CommonJS Async/A proposal as mentioned by TooTallNate & herby, thanks!