Exclude result prefix
No, exclude-result-prefixes never gives the system licence to change the namespace of an element or attribute. It only stops namespace nodes being copied to the result tree because they happen to be in scope from somewher higher in the stylesheet. Any element that's in a namespace (or in no namespace) so all elements and attributes will _always_ have whatever namespace nodes needed to correctly interpret the name. Such namespace nodes may produce namespace declarations in the serialisation irrespective of whether that namespace is specified with exclude result prefixes.
The XSLT 1 situation is that with a bit of care you have absolute control over what namespace nodes are in the result tree. so for example if you want a namespace node mapping "" (default namespace) to http://www.w3.org/1999/xhtml (XHTML) and "m" to http://www.w3.org/1998/Math/MathML (MathML) then you can do that.
then the tree has elements in the xhtml or mathml namespaces and a system can choose _any_ prefix it wants for those namespaces and add suitable namespace declarations, however since it must have added namespace declarations xmlns="http://www.w3.org/1999/xhtml" xmlns:m="http://www.w3.org/1998/Math/MathML" already, it would be peverse of the system not to use those prefixes.
In my experience most systems do use the prefixes specified in namespace nodes in the result tree. I've had to try quite hard to get any system to make up prefixes on the fly (the easiest way to force this is to copy several attributes with the same prefix but different namespaces in to an element, it has to rename all but one of the attributes to use new prefixes on serialisation)
exclude-result-prefixes and imports
You set it for each individual stylesheet module.
This means that the source text can be understoodd in terms of itself, plus any texts it depends upon (via xsl:include or xsl:import).
If instead, the importing modules settings were used, then you would need to read the set of all modules that depend upon the txt you are reading - a potentially unbounded set - many of it's members might not yet be written.
So this would be a very bad software engineering practice. Fortunately, the XSLT designers didn't do it that way.