Interesting performance challege (persistent child cursor mis-match)

Background:
This week we added an index for a very important ETL process to drive execution time down.
Subsequently we had a performance change in data ingestion process (100k records per hour) for a SQL_ID.

Ultimately, we put in 2 SQL Profiles and 2 SQL Baselines as the plan for the query will rotate between 2 acceptable plans and varies by day as there is a nightly job that rebuilds a temp table and repoints a synonym.
(PL/SQL now exists to rotate the 2 SQL profiles based on the synonym).

The INTERESTING part is that no matter what, we were still getting suboptimal child plans/cursors that were driving me a bit bananas. Even after flushing/invalidating all the plans for that particular SQL id.

This morning, I wanted to take a fresh look at it and approach it from a cursor level and understand what was different.

Which led me to GV$SQL_SHARED_CURSOR and mismatch information. (Which I was familiar with already but due to the "fire" of this performance problem hadn't had time to adequately research).

The MISMATCH for this cursor was on LANGUAGE_MISMATCH. I was like, "Hey, that's very interesting. Why is that?"

Turns out we have 2 separate (or more) client servers that go through the same code, and execute the same SQL.

The primary connecting server doesn't set NLS_LANG or OS LANG variable at all. And those sessions come in as WE8MSWIN1252.

The other connecting servers have LANG=en_US.UTF-8