> If it's full-name, certainly.  And I don't recall anything else that's standard in Windows that could be put in there, but XP was the last version of Windows for me.

WinAPI has a GetUserNameEx() function. We can get any of these :)

   NameUnknown,
   NameFullyQualifiedDN,
   NameSamCompatible,
   NameDisplay,
   NameUniqueId,
   NameCanonical,
   NameUserPrincipal,
   NameCanonicalEx,
   NameServicePrincipal,
   NameDnsDomain,
   NameGivenName,
   NameSurname

If we pay the price: <https://stackoverflow.com/search?q=getusernameex>

> That certainly works for me.  Or to be pedantic, some variation of
> full-name-and-maybe-more....

I've consistently had good luck specifying "raw" variants of procedures.
That tends to organize things naturally somehow.

The above Windows list has NameDisplay: 'A "friendly" display name (for
example, Jeff Smith).' Seeing it on that list, it feels more natural
than "full name". "Full name" is vaguely similar to "fully qualified
name". And displaying is the purpose of the name. After all, you can't
reliably parse anything from it (not even the surname). System accounts
can have anything in there (some BSD system accounts have jokes!) But
display-name says what it is geared toward.

Combining the above, we could have:

* user-info:display-name -- NameDisplay on Windows. Ampersand-expanded
first gecos subfield on Unix (unless implementor is sure they don't need
to parse it on the underlying OS).

* user-info:raw-display-name -- Raw gecos field on Unix. Same as normal
display-name on Windows.

And if the SRFI implementor does parse commas and ampersands for one
reason or another, the display will just be cruddy :) People are used to
getting crud on their screens anyway for any number of reasons.