@Adám The fundamental difference is that the translation is part of the Jelly interpreter, while your wrapper is not. If there's a way to modify APLK0=utf8 APLT1=utf8 APLT2=utf8 to take a different encoding, that would be something else. I really think you should take this to meta.

Prompted by this. I'll speak about Dyalog APL here, but this could really apply to any language.
Background
Dyalog APL has its own SBCS called ⎕AV. For backwards compatibility reasons Dyalog Ltd. is reluctant to change the character set. Lately, six new built-ins have been added to Dyalog APL a...

@Adám I consider all Python files in that repo "the interpreter". If Dyalog APL starts shipping with your transliteration tool, it would be the same situation. But once you need external tools to run the code, you have a different language. Imho, anyway.

Yes, it is. It just imports jelly.py, which could function as a library as well.

@Pavel Another possibility is counting Dyalog in delta-⎕WA (Workspace Available). This is the actual space used during normal operation and will take advantage of tokenisation and data packing. E.g. there is a 600 byte difference between the function {(+/∨\' '≠⌽⍵)↑¨↓⍵} and the function {(+/⌈\' '≠⌽⍵)↑¨↓⍵}.

@Dennis And workspaces too. The traditional way to store APL code and data is in highly optimised binary files where identical data and code can be shared among multiple symbols.

In the REPL, as soon as I close the editor (or press Save), my program is tokenised, and even the non-SBCS built-ins are mapped to single-byte tokens (although we are getting close to running out of those). There is a secret way to access the tokenised code, but I'm not at liberty to reveal it.

IMO, allowing transliteration is something we already do, and thus should allow in this case. Every program written in a compiled language goes through a transliteration step before being executed. A tool that translates from a SBCS to another encoding before running the code is just a compiler for our purposes. It should probably be mentioned in the language header to distinguish those answers from "pure" answers, though.

@Mego OK, one last Devil's Adv.: Right now, SBCS uses a fixed transliteration. Potentially, I could let the desired character set be a configuration option at "compile" time. This would mean that even challenges requiring up to about a hundred non-ASCII symbols would be solvable with Dyalog APL using a SBCS. OK?

@Adám Well sure, but that's why we have the loopholes post on meta - to keep things from getting too crazy

There's always going to be opportunities to abuse rules that aim to be inclusive. But we generally choose to close those loopholes one-by-one, rather than have a stricter set of rules that disallow languages/approaches that should be valid.