While this can be remedied by removing "read" from SRFI 172 as well, it does not solve the basic problem, namely that most of the R7RS procedures are only partially specified.
I will add language recommending (not requiring) that the implementations exported by the SRFI 172 libs do not provide any implementation-specific extensions over R7RS-large.
Therefore, I would like to strongly suggest to remove the sample/reference implementation of SRFI 172
A SRFI must have an implementation. It does not have to be flawless or portable, but it must exist to show that the thing (usually a library) described by the SRFI is actually implementable. SRFI 170 is stretching this to the breaking point, but most of it is still grounded in scsh.