> Show me any attempt and I claim that I will be able to show you its
> particular flaw.

OK, so there is more than one separate flaw.

> No; they are not shown to people. That's why the underlying record type
> is assumed to be opaque. The wording doesn't force the implementation to
> actually define a record type. If it wants so, it could use the
> following definition (assuming R6RS):
>
> (define-record-type fxmapping
>    (sealed #t) (opaque #t)
>    (nongenerative fxmapping-2bf340e5-304e-436e-8478-926c7040f3f)
>    (fields ...)
>    ...)

OK, in that case a UUID seems fine.

>     Another alternative is to allocate human-readable IDs and track them in
>     a table in <https://registry.scheme.org/
>
> This solution has two obvious disadvantages:
>
> (1) It needs a central registry outside the SRFI process.
> (2) It doesn't treat every SRFI fairly. Once a human-readable ID like
> "mapping" is registered, it can hardly be reused by a later SRFI. See
> the rationale of SRFI 97 why it is, say, (srfi :41 streams) and not
> (srfi streams).

Any reason not to simply use things like "srfi-146-mapping" and
"srfi-224-mapping" as the unique names? If the same type is used in more
than one SRFI, it could be numbered after the first SRFI it appeared in.