Usually, the module name is mangled along with the variable and subprogram names within that module. So it is typical that two different modules (with different names) could have variables or subprograms with the same names, but the mangling keeps them separate when the loader sees them. Here is a short example:
module xxx
real :: x = 1.0
contains
subroutine print()
end subroutine print
end module xxx
$ gfortran -c symbol.f90 && nm symbol.o
0000000000000010 s EH_frame1
0000000000000000 T ___xxx_MOD_print
0000000000000008 D ___xxx_MOD_x
0000000000000000 t ltmp0
0000000000000008 d ltmp1
0000000000000010 s ltmp2
Notice how xxx_MOD_ is incorporated into the two external symbols for x and print. Those are both common names, so it would not be unusual at all for different modules to also have an x variable or a print subroutine, and if they did, then everything would work correctly because of the name mangling. Of course, if a fortran subroutine USEs two of these modules, then it would need to rename those things in the USE statement to keep everything straight, but that is just local to the compilation step, it does not change any of the global symbol names.
The problem occurs when two modules have the same name. Then the name mangling alone does not solve the problem, and the global symbols that are generated would conflict. In the fortran source, there is no way to rename a module in the USE statement, so both modules could not be USEd at the same time. The resolution of this would require changes to both the global symbol mangling and to the fortran syntax.