I would avoid against [0] because it doesn't deal with astral characters. .toUpperCase() also feels "icky" but I think it's generally fine. I would recommend using regex though. Consider the following case:

const adlam = "𞤢𞤣𞤤𞤢𞤥";‎ // All lowercase: "adlam"
console.log(adlam[0]); // '\uD83A'; only a surrogate pair, not a character
console.log(adlam[0] === adlam[0].toUpperCase()); // true??
console.log(/^\P{Lowercase_Letter}/u.test(adlam)); // false; looks better

TIL 𞤢𞤣𞤤𞤢𞤥 is actually a valid JS Identifier - but tools really go wonky with it cos it's RTL.

Also worth noting that the regex approach is much, much, much slower.
Testing on my m1 on chrome:

• index -> 705M ops/s
• .startsWith -> 544M ops/s -> 23% slower
• regex -> 65M ops/s -> 90% slower

I think that in some codebases you're going to want to be i18n friendly and use the regex approach - but in a lot of cases the index approach is going to be just fine.

For example in our codebase I'm fine with us only supporting latin characters because that covers 99.9999% (i'd actually hazard a guess that it's 100% TBH) of usecases and is faster.

So what's the scope here? Here's my attempt:

checkFirstElementEquality: ignore the case where an equality expression is used and both sides reference string[0].

Because I assume we still want to report string[0] === "f". Do we want to report string[0] === string[1]?

Also for symmetry we probably want to treat the last element the same as well (string[string.length - 1] === string[string.length - 1].toUpperCase()), so the option needs a better name.

Breaking it down - we really have a two cases here.

1. string[0] === character
   • maybe a separate option for codebases that only cares for single-code characters?
   • probably want to refine the error message to highlight that it's not safe for i18n contexts.
2. string[0] === string[0].(toUpperCase|toLowerCase)()
   • maybe a separate option for codebases that only cares for single-code characters?
   • probably want to refine the error message to highlight that it's not safe for i18n contexts and provide the regex as an alternative.