Observations:

pw_gecos is not in the POSIX standard.
But it's been in UNIX(TM) "forever", and for those implementing this SRFI for UNIX or UNIX like systems, they may have less work to do if they can just return a low level suitably wrapped passwd struct record. That's certainly the case for Chibi Scheme.
There are ways to parse it with some degree of reliability, but they're not as standardized as the existence of the field, and are more subject to change than the existence of it.
We can specify a procedure and perhaps record type that'll parse it per the best known methods at the time the SRFI is finalized (research an implementor shouldn't be asked to do), which we can provide in generic Scheme supplied by the SRFI.
On the other hand, in Windows you should be able to reliably get a user's full name, or whatever was put in that field by a system administrator or end user. Perhaps other items as well.

I claim these are two separate things, and that we cleanly separate them for UNIX implementors, so they can primarily focus on the low level FFI, and simply supply the standard procedure to parse it with little or no change:

In the user-info level have a "comments" field which is the raw pw_gecos field, and mention in the description that it's named the gecos field for historical reasons, and note the procedure to parse it.

If the system is Windows, have the user-info procedure fill in this comments field in a manner that will be properly parsed by the supplied procedure. That violates the separation principle I mention above, but there will inevitably be a lot of that with Windows coming from a completely different branch of operating system history.

I think this satisfies all concerns except for the desire by some to never reveal the raw pw_gecos field, which I don't like since we know there will be non-standard unparsable instances of it out there in the sea of UNIX and UNIX like systems.

- Harold