Its up to the runtime.
Due to how the BEAM works, modules are lazyloaded, and only when the BEAM reaches the Rumbl.Accounts.User.foo() call the module is actually loaded and existence of the function checked.
So such a call will only fail at runtime. The compiler is long gone at that time.
This sound like a requirement of being able to do hot code updates on the beam. Sure it’s nice to have the compiler help in such situations (maybe it’s even possible with a custom compiler), but having the ability to have code loaded at runtime provides useful things as well.
If it can’t load a module then the PID attempting to access it crashes, no other PID on the BEAM system dies, that PID can then be recreated by, say, it’s supervisor and rebuild state with new code as appropriate, or if you do indeed have a programming fault then prepare for your logs to be spammed, but everything else will still keep working along fine. 
I.E. It’s very reliable.
Yes but it will be more reliable if the PID can find the module and wont need to recover (i.e. catch error at compile time).
Well if a PID can’t find a module, a programmer screwed up somewhere.
Besides, no such issues at release time anyway, all modules are pre-emptively loaded, it’s only during development that they are dynamically loaded.
You can’t hide, but you can obfuscate with really weird names. ^.^
It’s like Python in that way.