I agree, any suggestions? My naming skills is my weak point :)

startsWitch is the intended behaviour.
Ex:
"A.B.C".startsWith("A.B") -> state inside of the active
"A.B.C".startsWith("A.B.C") -> state inside of the active
"A.B.C".startsWith("A.B.C.D") -> state not inside of the active
"A.B.C".startsWith("B.C") ->state not inside of the active

https://stackoverflow.com/questions/17256182/what-is-the-difference-between-string-primitives-and-string-objects-in-javascrip

Ok, but come on, does it really matter ?

It's merely a consistency argument. If a reader reads 10x one variant, 5x the second variant, and 15x the other variant, he will notice the difference, wonder why it's the case. Only 5 seconds passed, but he will have the same thought everytime he goes through these. It takes up brain resources, instead the reader should direct all attention towards the original reason he had opened the file. (In general, if one keeps getting the same thought unrelated from the problem that one intended to work on, again and again when reading a file, there is probably something to that thought, fixing it removes the thought, sets one free. I need to test myself for autism some day.)

Shorter lines are better no? Having a s/p/o order doesn't matter is is more difficult to read.

Why would it be more difficult to read? I've heard that one often before, but it's a matter of habitualizing themselves to things without considering the alternative.

	let rect = updateBandbox("bandbox", msg.ev, false);
	let ents = Engine.PickPlayerEntitiesInRect(...rect, g_ViewedPlayer);
	g_Selection.setHighlightList(getPreferredEntities(ents));

	g_Selection.setHighlightList(getPreferredEntities(
		Engine.PickPlayerEntitiesInRect(...updateBandbox("bandbox", msg.ev, false),
		g_ViewedPlayer)));

I would claim the latter is easier to read,
and has the advantage that it the first thing that the reader reads is the purpose of the code setHighlightList,
rather than first challenging the reader to evaluate some helper variables before getting to know the cause for the helper variables to exist.

It reads:

Highlight the preferred entities in the bandbox of that player.

Instead of:

In the bandbox the entities of the player, highlight the preferred ones.

I've received a lot of hate for pointing this out, but it's the truth.
Code grows historically, we should not claim that to be the best choice merely because we came up with that variant first. Should always consider both alternatives, the pros and cons. It matters a lot if we chose one code style over the other in tens of thousands of lines. So we better pick the alternative that is best in the long term and leaves the code that is easier to read, even if some readers are habitualized to weird code.
I started coding in 2001 with QBASIC and that had no classes, no functions, only countless GOTOs (at least the code I was looking at). I got used to it, so I was unfamiliar with procedural and object oriented coding, so I could have claimed that was harder to read based on that. But if one wraps one head around it once, it's easier to have it cleaner, even if it takes some more steps to (re)write after obtaining the first working solution.

If one can order the statements logically and linearily (1 > 2 > 3 > 4), it's much more straight forward to read than 4, 2, 1, 3, even if the code result is the same. The more information we can transport to the reader, and the quicker the information is transported, the quicker the reader can decide on it, and the more qualified the decision will be, and he won't have to solve puzzles to start understanding and deciding.

Ok. Will be sent to input.js