Is a transliteration tool enough to grant count as SBCS?

Question

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 and have been assigned the symbols ⊆ ⍠ ⍤ ⌸ ⌺ ⍸ for mnemonic reasons, however these characters are not in ⎕AV. At the same time, ⎕AV contains 14 characters ɫ ¥ £ ¢ ý · € ´ ∣ ¶ ¿ ¡   § which are neither built-ins, valid identifier characters, or ASCII, nor are they used when pretty printing structures. They are therefore highly unlikely to appear in Dyalog APL programs.

It has been accepted that

the only thing that matters is there must be an actual file with the claimed byte count that, when fed to your interpreter, runs the intended program. How you interpret the bytes (or bits) in that file as characters is entirely up to you, as is whether you internally or externally provide conversion methods between the unreadable binary file and the readable ASCII-only interpretation of the file.

Let's say I provide a tool which packs a UTF-8 source file into a file using a SBCS more appropriately chosen than ⎕AV, and can also unpack such files. Does this grant me the right to count Dyalog APL as one byte per character even when using the problematic six characters? Or would this constitute a "new language" and my posts using this would have to actually display the (unreadable) bytes?

Does it matter that the user has to take a few simple steps to "compile" his (unreadable) "source"?

Would it help if I modified TIO's Dyalog APL wrapper so that it can actually run such files given an appropriate flag — even though it would in fact always run in "UTF-8 mode" when using the tio.run interface?

Speaking against this being acceptable is that then any code golf submission could just be zipped (being the wide availability of unzippers).

Speaking for this being acceptable is that while Jelly has a wrapper which can translate Jelly-encoded files to UTF-8 before running, TIO actually always uses the UTF-8 mode, as the Jelly source says:

This option should be considered the default, but it exists solely for scoring purposes in code golf contests.

Answer 1

Yes, it is valid

Consider C. In order to run a C program, it is first passed through a compiler (like gcc or clang), then a linker (like ld or gold), and then the resulting executable is run. We have no problem with this (but we require the compiler to be specified, since different compilers implement the language differently, and thus by our rules they implement different languages).

Thus, passing a SBCS-encoded program through a decoder, and passing that output to the actual compiler/interpreter/whatever, is also valid. It's simply another compilation step.

However...

Use of such a transliteration needs to be clearly mentioned in any answers, to distinguish them from answers which do not make use of the tool. The tool plus the compiler/interpreter/whatever form a different language by our rules (since the implementation defines the language), and so such answers need to be clearly distinguished.

One would not argue that Japt is not a programming language. One would also not argue that it is the same language as JavaScript (despite transpiling to JavaScript before being executed). The same logic applies for any transliteration tool.