This page is part of the web mail archives of SRFI 106 from before July 7th, 2015. The new archives for SRFI 106 contain all messages, not just those from before July 7th, 2015.
If I understood your point correctly, the purpose to keep the name was prevent double looking up. If it's not, sorry ignore the below.as or consistent names with well known names since R6RS has rename import and export and R7RS will have the same mechanism.I don't get why rename import/export is related to my point. You're concerning that reading someone's code that renames identifiers defined in srfi? Well, that happens anyway, but in reality most people don't bother to rename them.
Say if somebody creates a new abstract layer but just export some variables with renamed names from the lower layer, because of the author's preference or other APIs consistency. Then when the users need to know what those variables mean, first they need to look up the document for the abstract layer, if it just indicates the lower layers document then they, again, need to look it up.
My point of view for this problem, there is no silver bullet for it, even if we keep the name. In reality, people try to avoid this but not 100%, it's because in some context it might not be the same name but the same behaviour, then proper solution could be rename it.
With this SRFI, this might not be applied since socket APIs are de-facto standard.
-- _/_/ Takashi Kato E-mail: ktakashi@xxxxxxxxx