> A SRFI name is conceptionally just an identifier
> (however, one that is allowed to be an ordered compound of symbols and
> not just a single symbol).

Are you referring to the following passage in SRFI 97?

"There is opportunity for grouping related SRFIs together. For example,
SRFI 28, Basic Format Strings, and SRFI 48, Intermediate Format Strings,
could be grouped into a common format library with simple and
intermediate components. This has been avoided, preferring instead to
follow a one SRFI, one (top-level) library convention. Although within a
single SRFI, several sub-libraries can be defined, thus achieving
grouping. This simplifies the naming convention and prevents the need
for a naming authority which decides what shall and shall not be grouped
together. Instead, grouping must be achieved by the SRFI process, as it
should."

SRFI 97 gives the following examples:

(srfi :41 streams primitive)
(srfi :41 streams derived)

But it is silent on how to use sublibrary names without main library names.

Should we never use a sublibrary name without a main library name? That
violates the spec of some existing SRFIs that were written with R7RS in
mind, e.g. SRFI 160 says (srfi 160 base).

IMHO this demonstrates that it's a bad idea to address meta-level
concerns like library naming in individual SRFIs.

> As I remarked several times, for some syntactic extensions (like local
> imports), we need at least the name part of a library name to be a
> symbol (so that it can carry lexical information).  The best we can do
> for R7RS-small names is to somehow map a number like 227 internally to
> :227.  The positive side effect is that R6RS and R7RS names for SRFI
> library names become then interchangeable (simplifying porting).  The
> upshot is that we don't want to give different semantic meanings to a
> number or the ":"-prefixed symbol arising from the number in library
> names and library name parts.

The right thing is (symbol->string '|123|) => "123"

R6RS doesn't have |...| syntax but I hope we can get past that in
implementations.

Making the :123 hack equivalent to 123 is something that should be
solved on an ad hoc basis in the library loader. Hacks shouldn't go into
RnRS.