(srfi 181) could be the library including both sublibraries (as in SRFI 166).

Then we would have (srfi 181 custom-port) and (srfi 181 port-position).

All three libraries could be optional, which could be tested against
with cond-expand. For R7RS-large we are again free to choose the
library names and their optional status.

Am Mo., 6. Juli 2020 um 08:29 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> On Sun, Jul 5, 2020 at 8:20 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Mo., 6. Juli 2020 um 06:59 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>>
>> > The only thing is that some implementations may want to, or can, support srfi-192 but not srfi-181.
>>
>> This could be done as in SRFI 166 or SRFI 155 through sublibraries,
>
>
> They split the library to the base part and the optional part.
>
> In srfi-181/192 case, if srfi-181 is supported, not supporting srfi-192 doesn't make sense, but not vice versa.  So, srfi-192 is the base part and srfi-181 is the optional part?
>
> If that's the case, the srfi should be about port positionings, with optional custom ports (in other words, it make sense to merge srfi-181 into srfi-192).
>
> But I'm not sure... custom ports itself doesn't look like a sublibrary of port positioning.
>
>