Rewinding one click:
This last example shows that the syntactic environment of the
*imported* identifier public is the one of the importing
library/module.
Ok, I agree with this statement. I had it backwards in my head when I first read it. (It's like when the cashier at the grocery asks me credit or debit for my card, and the word "debit" is close to the word "debt", which is what a credit card causes, and "credit" can be a synonym for "refund", which is not what I'm expecting, and it always takes me a beat to respond correctly).
Maybe we should only communicate via well-written scheme test-cases from now on. ;-)
So, this all winds back to your concern that we need to be mindful of the different behaviors of different approaches to library composition or aliasing. Personally, I think in this case no contracts are being broken. If you have to use datum->syntax to detect the differences (and minimal collaboration from the libraries involved to expose their internal contexts), then nobody should be able to claim foul when a library is re-composed in a different way. If you have a plausible real-world counter-example, I'd love to see it.
Unwinding further, you asked my opinion about define-library-alias vs. alternative library composition declarations:
I agree with you that define-library-alias is fundamentally different from any of the composition options, though mainly only in ways of efficiency, not semantics. I agree with John that a representation of library aliases is not something we can really standardize without first establishing an additional standard that talks about files, directories, and perhaps a place to put the alias table(s) you suggested. There's not a lot of benefit to replacing one file that imports and re-exports a bunch of ids vs. a file that says it aliases another library -- in both cases the file still has to be read (and in an auto-dependency checking system, re-read or at least stat'ed if you trust modification timestamps) -- other than semantic clarity. Your table method is more likely to produce an efficiency benefit. In the end, I am in favor of the concept that the mapping from library-name to library can be many-to-one.
Independent of the application of library aliasing, it would be nice to have a *-ish export feature. (srfi 160) being a composition of (srfi 160 u8), (srfi 160 s8), (srfi 160 f32), ... comes to mind as a use case as the list of ids there is very long, and when implementations support additional numeric formats (like I play with), it really helps with maintenance.
I like my export-from declaration (accepts arbitrary import specs, and only re-exports, does not import) because if I also want to import the same ids, I can do that separately.
export-all is not my favorite as it seems to be useful in only a very limited set of cases. If any local code is to be added, you can't have un-exported helper functions/macros.
extends -- either it can only be used on a single library (single inheritance) or if can be used more than once, it's just a version of export-from or (export (from ...) that cannot apply renamings or subsetting to its arguments. I highly prefer the concept of composition over inheritance/extension.