So while indexing the SRFI's available in Chibi scheme (see the other
thread), I've observed that there were two SRFI's that although are
supported by Chibi are not available to import due to their nature:

* SRFI 22 -- the one about running Scheme scripts on Unix;
* SRFI 62 -- the one about s-expression comments (which are also
required by R7RS);

Now indeed, as Alex Shinn pointed out, there is nothing to export from
those SRFI's as they are "builtin" in the Scheme interpreter and
tightly coupled with it.

However it made me wonder why shouldn't there be an actual import,
even though it wouldn't do anything?

For example in case of SRFI 62, by using `(import (srfi 62))` one
explicitly states that one wants the interpreter to support value
comments.  If the interpreter doesn't support value comments, then the
import would fail, and if it does support it it would just import
nothing.  (Else if the module uses such comments, and the interpreter
doesn't support them, the user will end up with a syntax error and not
with an explicit message like "SRFI-62 not available".)

In case of SRFI 22, a script starting with `(import (srfi 22))` would
explicitly state that this file is not a module, and it should in fact
be executed as a "script".  In case the interpreter was started as
such it would succeed, else it would fail.

What I am proposing is that for any SRFI, if the interpreter supports
it in any way, even builtin, the statement `(import (srfi n))` to
succeed.  Moreover any "portable" Scheme library or script, if it
requires a certain SRFI to function it should always import it.

Moreover, there is the `features` (and `cond-expand`) mandated by
R7RS, however it doesn't contain anything related to SRFI.  Shouldn't
there be some standard (as per SRFI) way to use it to flag that a
certain SRFI is available?

The advantage of doing so would be that one could write "portable"
SRFI's in the sense that in the case the SRFI doesn't have a "hard"
requirement of a certain SRFI, and that dependent-upon SRFI doesn't
exist, the original SRFI could provide some sub-optimal implementation
for the required functionality.  (I remember reading some SRFI's about
records or such, and they state that certain features could be
implemented "like so if SRFI-X exists" or alternatively "like so if
SRFI-Y exists", etc.)

Even the SRFI-0 (which defines the `features`) states:

~~~~
The SRFI registry is used for this purpose. It is expected that
features will eventually be assigned meaningful names (aliases) by the
SRFI editors to make reading and writing code less tedious than when
using "srfi-N" feature identifiers.
~~~~

What I am proposing is that for any SRFI that a particular
implementation supports, it should also provide the symbol `srfi-n` in
the `(features)` output, just as envisioned by the original SRFI-0.

Ciprian.