Q:

Jelly- can we really score it by character count?

Jelly is one of those languages that doesn't use ANSI text in its code. Why should we score Jelly by its character count when each character can take up to 4 bytes?
For example, take this answer (Authored by Dennis):
ḃ2-*µSN;+\>-Ạ
1Ç#Ṫḃ2ṭ2;1ị⁾][

From a character counter, one can see that this is exactly 28 characters (which is how Jelly is currently scored). However when I save this into a txt file (with no metadata in the file size), it could be up to 112 bytes (28*4). However, when saved onto an uncompressed disk, it is 60 bytes. This is still many times more than what is currently scored. I may reference my Excel scoring thread, with users agreeing that excel can be scored by file size in indeterminate cases. It seems that the same should be done with Jelly- as its' characters DO take up more than one byte.
IF as a community we somehow decide that this isn't the case, and we should judge jelly by its character count alone, Then I will have something to introduce to the community soon-ish.

A:

Jelly uses its own code page and the interpreter is capable of reading files encoded in this code page. Hence, it's actually possible to feed a working file of the claimed size to the interpreter and therefore the byte count is completely legitimate. Here is the relevant meta post which says that answers can use any encoding of their choice, as long as it existed before the challenge and is actually executable.
Note that this doesn't give Jelly any unfair advantage over a language that doesn't invent its own code page: one could equally well write a golfing language which uses all 256 characters of some standard code page like the extended ASCII standard ISO 8859-1. It's just that in that case a lot of the characters would be unprintables, which would be a lot more annoying to work with. The only advantage Jelly gains from defining its own code page is that all the characters are printable (and even typeable on an International US keyboard layout) and allow Dennis to choose nicer mnemonics for the individual commands.

A:

As Martin already explained, Jelly uses a custom code page that is incompatible with ASCII and UTF-8. This isn't a made-up way of counting bytes, but the Jelly interpreter can take the source code (and input/output, if desired) using this code page. This is actually the default for the official interpreter, which requires the u flag to process UTF-8 encoded source code.
For the answer in question, the byte count with Jelly's code page is in fact 28 bytes, and the 28 byte file is functionally equivalent to the UTF-8 encoded 44 byte file.
$ cat nest-utf8.jelly; echo
ḃ2-*µSN;+\>-Ạ
1Ç#Ṫḃ2ṭ2;1ị⁾][
$ wc -c nest-utf8.jelly
44 nest-utf8.jelly
$ xxd -g 1 nest-cpj.jelly
0000000: e7 32 2d 2a 09 53 4e 3b 2b 5c 3e 2d ab 7f 31 0e  .2-*.SN;+\>-..1.
0000010: 23 ce e7 32 e0 32 3b 31 d8 8e 5d 5b              #..2.2;1..][
$ wc -c nest-cpj.jelly
28 nest-cpj.jelly
$ jelly fun nest-utf8.jelly 8
[[[[]]]]
$ jelly fn nest-cpj.jelly 8
[[[[]]]]

If Jelly was only able to process UTF-8 encoded files, I would have to score (and would have) the answer as 44 bytes. However, since there is a 28 byte file that solves the task at hand, I am able to claim a score of 28 bytes.

