In this case, some option values are optional, but none of the options are. This reads in a kind of chewy way. Perhaps:

In my comment on 838, I suggested that we might want to break these into separate functions. There is a certain appeal to that, particularly since the options interact and since we want to encourage structured monetary and unit types.

Eh, that probably works for me too. What about percent formatting? Should that have its own function as well?

I think percent is fine where it is? It's more like scientific or other presentational gorp for formatting a pure number (you never really see a Percent type walking about). I could be convinced otherwise, though.

We do also apply this transform to percentage values:

If there's reason enough to define :unit and :currency, it would make it much easier to also define :percent, and not allow any of these to be used as operands.

The transformation for percents is multiplying a number/moving the radix. It doesn't require changing the type or any external data. We could add a per-mille formattnig too and @macchiati has proposed adding offset. These are all pure number things, which is why I'd keep them together with :number/:integer.

Units and currencies have a host of specialized options and accept different types. That's why I'd separate them: they are only numbers because they contain numeric values and want to select like numbers.

I wouldn't object to providing a :percent function. I don't think it is required that we do so, obviously. But maybe we do it for consistency?

This should not be optional for implementation for the reasons I cited in #838. Best practices are cool, but users should not be require to box up currency values in their legacy applications.

I'm not sure that I understand your comment here. Do you mean that we ought to require all implementations to support an option specifying a currency code?

No, but if you support style=currency then you must support the currency option. This says MAY.

I don't see why such a requirement ought to be placed on all implementations that support currency formatting. I agree with @macchiati in #838 (comment) that this can be solved in user-space instead.

It might be solved in the user space. Users are encouraged to do so.

But my experience is that there are many applications that are mono-currency or which provide the currency contextually (at the document/record/transaction level). I see these people who are somewhere along the internationalization curve and it is a hard sell to get them to refactor their application just to format a number as a currency.

There are many runtime environments in which there is no currency value class/object/structure built-in: people have invented their own. Providing a way for these applications to work reasonably I think is important too.

But, finally, I think the key thing is that our functions/option sets should be as portable as possible. It simplifies the work for tools and editors and the learning curve of developers. Where we have optional functionality, the package should be as consistent as possible. Implementations can extend it, but those options will (we hope) be namespaced.