Sorry about joining late in this thread.

> I see.  That sounds reasonable.  In the reference implementation,
> transcoded ports are already in a separate sublibrary internally.  If we
> have port-position and custom-port sublibraries, would it make sense to
> split transcoded port as another sublibrary?

I would advise against SRFIs having optional sub-libraries. It's useful
to be able to say that a Scheme implementation "supports SRFI nnn", and
since most or all SRFI have no optional features, the situation has so
far been simple for users to understand. If SRFIs start having many
optional parts, that peace of mind will no longer be there.

Optional features are natural in cases where a SRFI interlocks with
another SRFI. For example, a filesystem SRFI can take filenames as
strings, but specify that if pathname objects are supported then it
takes those as well. The pathname support is an optional feature since
it won't be present in all implementations. But adding a new sublibrary
with entirely new features is not a simple variant of the required
behavior in this way.

Claims of the form "Scheme implementation Foo supports SRFI nnn" are
featured in many places: cond-expand identifiers, SRFI 176 output,
websites, manuals, casual conversation, etc.