Due to the preprocessor parsing numbers differently than Lua, here are some issues:

Valid code (1e-3 is a valid number in Lua):

a=1e-3

Invalid code (1e-3 is parsed as 1 e - 3 by the preprocessor):

a+=1e-3

Invalid code (2b is an invalid number in Lua):

a=1+2b=3

Valid code (2b is parsed as 2 b by the preprocessor):

a+=1+2b=3

There are 3 things in conflict here:

1. There should be a consistent definition of valid number forms
2. PICO-8 shouldn't stray too far from standard Lua (ha!)
3. There's plenty of a+=1+2b=3 in the wild (and it's kind of handy for tweetcarts)

It's tempting to just drop support for the exponent form altogether. They're not very useful within the 16:16 numerical range, and standard Lua snippets from outside PICO-8-land containing exponents would often be silently broken for the same reason. Accepting numbers immediately followed by identifiers (a=1b=2) is a more severe violation of 2, because it can happen in otherwise valid standard Lua. But I'd be willing to sacrifice 2 in this case in favour of 1 and 3 (tweetcart-friendlyness).

In that case, the first 2 statements would be invalid in PICO-8:

a=1e-3    -- same as: a=1    e-3
a+=1e-3   -- same as: a=a+1  e-3

And the second 2 would be valid:

a=1+2b=3  -- same as: a=1+2   b=3
a+=1+2b=3 -- same as: a=a+1+2 b=3

well I didn't even know about that exponent syntax in Lua so I for one would not miss it if it got dropped :p

You might want to consider syntax expansion opportunities. If decimal number literals don't require a trailing separator, you're sacrificing a future possibility of a token type that looks like a decimal but contains characters outside [\d\.]. The only use case I can think of is to add back support for exponents so maybe this isn't a big deal, and new number literal types probably need prefixes anyway.

Dropping exponent support is compelling because of PICO-8's narrow fixed point number type. You might want to consider whether this "flavor" of Lua will be used in other contexts with other needs. This might meet Voxatron's needs also, but the interest in using this Lua flavor in two places suggests potential for a third product.

Consistency between forms would be my personal priority. The break from standard Lua is easier to accommodate if there is a clean translation rule between PICO Lua and Standard Lua.

FWIW, CBM BASIC tokenizes keywords without separators. I remember doing type-ins as a kid and wondering what the heck FORK=1TO100 did. :)

I'm hardly a tweetcarteer, but if I wanted to have a number 10000 or 1000 in the fewest characters, wouldn't I have used 1e4 or 1e3?
Unless there's a crazier shortcut, I'd be surprised if no tweetcart uses exponents.

Infact - just google "tweetcart 1e4" - several examples just for that number.
1e3, 2e3 and 2e4 gives more examples, too.

I think allowing smushed commands over basic exponent syntax isn't great, just because it could cause more surprising bugs in non-tweetcarts. I mean, examples 3 and 4 look fine in the context of many other smushed commands, but in a typical cart with whitespace I think the first two commands would be encountered more often.

It's possible you could split expressions by capturing the token preceding an '='/'+='/etc assignment symbol, since you can't chain "a=b=c" in standard lua. Since "e-3" isn't a command you'd encounter often on its own, it may be worth supporting this exponent syntax of 'e' plus a number over any conflicting variable named 'e'.

With that being said, I think 1e4 will probably work as expected in PICO-8 right now, it's likely the '-' in "1e-4" that is tripping things up.

I think consistency is the most important factor. It is really bizarre that a+=1 is not parsed like a=1.

Note that people who would like to do a+=1+2b=3 in their tweetcarts have more than 40 other valid characters at their disposal, e.g. a+=1+2k=3 or a+=1+2★=3.

Also since P is the character for hex exponents (that the PICO-8 Lua system can parse, but the PICO-8 numbering system cannot), there is this additional discrepancy:

a=0x1p3=12   -- same as: a = 0x1p3 = 12
a+=0x1p3=12  -- same as: a += 0x1 p3 = 12

Lua standard allows lowercase or uppercase exponents e.g. 1e-3 or 1E-3, and 0x1p3 or 0x1P3. Although not very intuitive, you could consider dropping support for the lowercase exponents but keeping support for uppercase, now that we have the puny character set. Then you get the proposed #1 and #3, and half of #2.

Just noting my two thoughts - I think that if you run into a 'reserved' form, it should prioritize that (0x, e). Here are a list of inputs, and how I'd expect it to be interpreted:

a=1b=2      :   a=1       b=2
a+=1b=2     :   a=1+1     b=2
a+=1e-3     :   a=a+1e-3
a+=1e2b=3   :   a=a+1e2   b=3
a+=0x1b=3   :   a=a+0x1   b=3

For Fun-
a=b+=c      :   b=b+c     a=b
a=1b+=c     :   a=1       b=b+c

And I'd expect each assignment operator to act the same way (Eg: *= <<=)
Basically, you'll want to be careful using e/x unintentionally in tweetcarts, but otherwise I'd think you should be good.

@BLOMP_David I think this is not possible to implement in Lua, because the lexer is not allowed to backtrack. When reading "=" after "0x1b" it has already sent 0x1b to the parser and cannot go back and decide that it was actually "0x1" followed by "b".

Also, which of these would be correct?

a+=0x1b1b=3    : a=a+0x1    b1b=3
a+=0x1b1b=3    : a=a+0x1b1  b=3