user-login-name, which as Lassi notes, "is reliably accomplished via (user-info:name (user-info (user-uid)))", that the passwd database is the source of truth, but the routines that query it can be overridden with e.g. a LD_PRELOAD hack. John agreed user-login-name should go, I will add a note pointing out Lassi's alternative.
I originally advocated against all of 3.6 User and group database access, user-info and group-info, but there are solid arguments for them including the above observation by Lassi.
I note group-info:members is particularly messy to get back from the library call, and Lassi notes "getgroups() [ which the SRFI supplies as (user-supplementary-gids) ] gets the full list of your own supplementary groups."
Therefore I advocate we remove group-info:members from the group-info record, and make a note about user-supplementary-gids in the 3.6 section.
I further advocate along with Lassi that pw_gecos from the passwd struct be added to the SRFI in the user-info record. We could call it either full-name or full-name-field, the latter suggestion because other stuff has been added to it in times past.
We should consider if pw_shell in this struct satisfies the 80/20 rule, or omitting it violates people's expectations. Fields in a record from a struct are normally particularly cheap in pretty much every way.
current-timezone, which can be picked up from the TZ environment variable, and in general deserves being part of its own SRFI.
uname, which I noted that with the existence of uname(1) would only be useful for automated bug reports, and John noted "Most of what's important about it is provided in (features) in more useful form."