>> Is it possible that some SRFI x Scheme implementation entries are missing because the SRFI is portable and so implementers don't need to incorporate its code into their own source code?

It depends on the Scheme implementation. E.g. our chicken.sh scrapes the
wiki page at <http://wiki.call-cc.org/supported-standards>. That page
lists the SRFIS bundled with Chicken as well as those available as
third-party eggs.

Most of the other scrapers grep in manuals or source files, which
generally only takes built-in SRFIs into account.

> It would be nice to know which Schemes can trivially support particular SRFIs just by loading their sample implementation.

That may be a substantial list, but I wonder how many of those are good
to use in practice.

> If that's the case, those SRFIs should be added to some repository
> like Snow. We know if it's portable by looking at the repo, and the
> user can also get it easily. We could reserve a namespace in snow for
> srfi reference implementations.

This is probably the ideal way to implement the above (short of bundling
tailor-made SRFI implementations with each Scheme, which is more
time-consuming, and implementors often don't even want to include all
SRFIs with their Scheme).

> I could start with some srfi that I know from experience is portable
> enough. But I think we need to make sure srfi editors have the right
> to update these packages if needed (haven't looked closely at snow
> yet)

That would be great.

Snow packages should all have an email address somewhere in the package
metadata (if you download the tar file from snow-fort.org and grep for
'@' you'll probably be able to find it). Reaching all the different
authors could take quite a bit of time and work.

A unified "r7rs-srfi" collection could also make sense. The chez-srfi
package (from Akku) despite its name is effectively "r6rs-srfi" now. It
explicitly supports several different R6RS implementations. The same
could be done for R7RS.