>> Transparently calling lambdas is a particularly nice way to solve
>> problems like this, since we don't have to decide ahead of time which
>> properties need a lambda (for things like localization).
>
> That only works for the special case of a lambda that takes no
> arguments, right?  Not very transparent if you know you have to hand
> it a language argument....

You're right. Only the zero-argument case is properly transparent.

To handle arguments, there'd have to be some kind of fallback so that a
lambda returns #f if it gets arguments it does not understand. And if a
property doesn't have a lambda but foreign-status-ref is given arguments
anyway, it would just drop those arguments on the floor. It doesn't
sound very reliable to be this lenient.

To be reliable, we'd need to restrict the properties taking arguments to
particular ones known in advance. And those properties would need to
have a stable calling convention so that they always take the same
number of arguments of the same types.

For localization, we could have 'message and 'localized-message
separately. The former would be a plain string or a zero-argument
lambda. The latter would always take one argument, which would be a BCP
47 string if we can make those work easily.

Then duplicate it as 'message-detail 'localized-message-detail. Plus
'message-hint and 'localized-message-hint.

It gets a bit verbose, but is not beyond hope.

We could also have a 'localized property which lists the names of all
properties that have localizations. Any of those other properties could
be queried with a BCP 47 string as an argument, and would respond sensibly:

(or (and (memq 'message (foreign-status-ref st 'localized))
          (or (foreign-status-ref st 'message "fr-FR")
              (foreign-status-ref st 'message "en-US")))
     (foreign-status-ref st 'message))

> Yes, and thus "raise-foreign-error", exactly that text since I assume
> you won't be raising a non-continuable "status", and "error" makes its
> purpose more clear.

It does, but if we're calling the type foreign-status then the raise
procedure should probably be raise-foreign-status to match. Or something
like raise-foreign-status-as-error, but that's probably not less confusing.

>> Does it matter to the spec how these internals are handled?
>
> I suppose not, it's either "do exactly what make-foreign-/whatever/
> does to create the object to raise", or "call make-foreign-/whatever/
> to get the object to raise."

Yes - the usual "as-if" principle ought to work here (i.e. interface foo
works as if it did such-and-such, but may do something else that gives
an equivalent result).