We have previously contemplated what to do about current-locale, per Lassi it's much less useful than us US people would think, although John noted it's important for date formatting, and I note it's grossly under-specified unless we just return something like what the Linux locale(1) returns on my two systems:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Or OpenBSD:

LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

Perhaps defer to a localization SRFI? Which could ideally allow fine grained control so one could for example run a Japanese Scheme application such that it think it's native, with an Input Method Editor (IME), while the system is naively Anglosphere or European.

- Harold