export makes one or more symbols that are accessible 
in package (whether directly or by inheritance) be external symbols
of that package. 
If any of the symbols is already accessible as 
an external symbol of package,
export has no effect on that symbol.
If the symbol is 
present in package 
as an internal symbol, it is simply changed to external status.  
If it is accessible as an internal symbol via use-package, 
it
is first imported into package,
then exported.
(The symbol is then present in the package 
whether or not package continues to use the package through 
which the symbol was originally inherited.)  
export makes 
each symbol
accessible to all the packages that use package.
All of these packages are checked for name conflicts:
(export s p) does
(find-symbol (symbol-name s) q) for each package q
in (package-used-by-list p).  Note that in the usual case of
an export during the initial definition of a package, 
the
result of package-used-by-list
is nil and the name-conflict checking
takes negligible time.
When multiple changes are to be made,
for example when export 
is given a list of symbols, it is
permissible for the implementation to process each change separately,
so that aborting from a name
conflict caused by any but the first symbol in the 
list does not unexport the
first symbol in the list. 
However, aborting from a name-conflict error
caused by export 
of one of symbols does not leave that symbol 
accessible
to some packages 
and inaccessible to others; with respect to
each of symbols processed, export
behaves as if it were as an atomic operation.
A name conflict in export between one of
symbols being exported and a
symbol already present in a package 
that would inherit the
newly-exported symbol 
may be resolved in favor of the exported symbol
by uninterning the other one, or in favor of the already-present
symbol by making it a shadowing symbol.