I don't think that this is important enough to justify changing module.js, sorry. We've never claimed that module.require and require are the same function. Can you point to a use case where this matters?

Thank you for your responsiveness !
Yep, ok, I understand that. Extra, the module.js is locked: stability is clearly a priority over this suggestion.

There is two low level motivations to my suggestion and one high level use case :

1. According to the documentation, the module.require method provides a way to load a module as if require() was called from the original module. I think that it make sens to provide the same low level access to require.resolve : that for the same reasons we provide access to module.require.
2. Both have the same name, it look like to be the same, it should to be the same... but it is not : that disturbing and not very consistent.
3. A high level use case : In a framework, we use to simplify things for user by providing low level and recurring actions automation. Maybe that the goal of module.require : by explicitly providing my module object to you, I want you to do think as if your are me... Frameworks reduce boilerplate code by defining such contract and convention (filename, directory structure, etc.). For exemple, a framework plugins register him self in the framework and let him resolving absolute path to some ressources he provide.

Anyway, the framework use case is easy to resolve with external path resolver : What motivated my suggestion is foremost the consistency question noted above.

Many thanks for reading this and for the great work done by the Node.js team.
(I hope I was understandable: as you can see, english is not my native language ;) )