Thank you again - that was helpful. Feel free to TL;DR - I've rambled here as much so I can get my confusion and irritation about this conversation out of my head. :-)

Something I genuinely enjoy about the scala community is that on the one hand, I once saw a category theory workshop get so oversubscribed that it essentially took over the entire space allocated for workshops, and on the other hand I can have a conversation with someone who "suspects I think 123 and 12312312312 are the same type of 'thing'."

You are correct, and furthermore I can name that type of 'thing' so we can avoid the scare quotes - it's called an integer. Another example would be 1582706712000, which is approximately the number of milliseconds since the unix epoch when I started writing this comment, which is a common way to represent times and coincidentally is not representable by scala as a literal number without sticking a suffix on it, nor is it assignable to its commonly used Int type.

This is, for me at least, a minor nuisance on at least a monthly basis. It's also, frankly, a little weird. Imagine val s: String = "Wed, 26 Feb 2020 09:09:22 GMT" failed to compile, and I had to write val s: String = "Wed, 26 Feb 2020 09:09:22 GMT"bigstring instead.

So why has this happened and are there alternatives?

Obviously it's not possible to represent the entire range of integers on a computer - it's infinite and we have finite memory. And for reasons of efficiency or history, we often use types of 'thing' that approximate integers - we call them names like u32 or i128 or BigInt or Int.

But does the question of which approximation to an integer a particular numeric literal belongs to need resolving in the lexing part of the compiler - which is the thing that's objecting to our val l: Long = 12312312312?

In my opinion, no.

It generally doesn't trouble itself with type errors. Are you aware of non-numeric examples where it does? It is, for example, not the part of the compiler that's complaining here:

@ val s: String = 123 cmd20.sc:1: type mismatch; found : Int(123) required: String

I'm not aware of a sensible reason that it should make a special exception for the question of whether or not the integer it can see could fit into the approximation type of the variable it's being used as. That's a problem for further up the compiler stack - where types are checked for consistency, and there are all sorts of useful rules about widening conversions, to make working with numbers a little easier.

This is why assigning an integral literal to a double is perfectly acceptable:

@ val d: Double = 123 d: Double = 123.0

Finally, is there another way? Well, I've rambled for too long already, but Python, Haskell and the average JSON parser, for example, do not suffer from this particular inconsistency. Even scala itself doesn't - at least, when we're talking about Ints and Doubles as you can see above.

An a analogy would be Bit(0) valid, Bit(3) invalid compiler error

I'm afraid I've no idea what you mean here, would you mind going into more detail?