Michel Hermier

This is too much for us to maintain for now. The easiest solution is a configuration hook and a best effort fallback with ascii-7 support and no promise on the...

Well the minimal requirement for the notion of casing is ascii-7 because of the capital letter naming rule. Guaranteeing more is just superfluous bonus. So even if in implementation we...

Identifiers already have UTF-8 requests, so identifiers are already on the same basis as text. The thing is that by rising the minimum guarantee, you are increasing code that is...

It does not bring anything that an external function could do. And it makes precedence on the notion of casing. So it is still not good. It should call a...

> * Fully support Unicode upcase/downcase in Core For ease of use, this means having a reference utf-8 library. Not a big deal, but can have some issue because of...

Considering the current state of the code, this would be the way to go, but will be a huge breaking change. Personally, I would go another route and make `WrenBindForeignMethodFn`...

It is not a problem of opcode, since the situation can't be resolved at compile time. The thing is that your change implies modifying the signature of the foreign method...

Took a quick look at it, and while your implementation is fine as this, I would have prefered to have userdata as first parameter (but this is a personal taste)....

That's the beauty it is transparent. Yon only simply have to call it always with the private data on the calling side, and in the called functions unused parameter will...

Would it makes sense that to avoid these problem in the future we provide macros like we do for built-in but for foreign?