I can tell you, you’re much better off using FSLTL over live traffic. You’ll get better model matching and you’ll get an overall much better experience. All of my testing between live traffic and FSLTL was using AIG models and liveries and they matched and worked just fine. I don’t know how in depth MSFS correlates airline codes with regional partners but that’s something that has not been an issue within FSLTL for a long time. The best way is to test using the callsigns for the flights. So if you have a Skywest flight used by Alaska that is showing a Delta Connection aircraft then that’s an issue. You need to be able to provide some more concrete examples. You don’t have something set right because in my testing with generic models off, all of my live traffic was pulled from the AIG folder. You can see my results here: Live real world air traffic in msfs...is it real? - #48 by UpstateElf898
Are you saying that the Asobo ‘Live Traffic’ models & liveries matched-up correctly?
(as distinct from FSLTL-injected traffic)
They matched up to what was installed in my Community folder with AIG. So yes, they matched. Did you install everything using OCI in AIM?
yes – all the main airlines that you would see at any international airport
The in-sim live traffic can be inconsistent when doing model/livery matching, regardless of whether you have AIG and/or FSLTL models/liveries installed.
Using the FSLTL injector or AIGTC, you obviously get much better success rate. But if you choose to just use the in-sim live traffic, then yes, you can expect some aircraft having no livery or having the incorrect livery… has been that way for quite some time.
Regardless… doesn’t have much to do with the topic in this post though…
Yup. Live traffic is quite the mess. Since pulling from FlightAware the only data directly available is the main parent company. So the flight is read as Skywest which is simply SKW/OO. But the difference between who operates the flight is through the callsign. Skywest under United Express or Endeavor under Delta Connection both operating flights on behalf of Sktwest. If they read from the callsign of the flight and not from the generic parent airline then you would have much better matching.
That is great to hear, but unfortunately it seems that Asobo do not like to issue hotfixes, so we will have to wait until the next sim update, which I believe is not until August 
A temporary solution for users is the AIFlow/AIGround addon combination which has an option to force landings. It is not a global solution as it has to be configured per airport and runway in the ini file and the result is rather jerky landings as it fights MSFS to get aircraft on the ground in a reasonable distance.
Although I am sure that AIG could incorporate a similar fix it is perfectly understandable that there is reluctance to do so because the resulting jerky landings would be unacceptable and better to wait for Asobo to fix the problem.
I tried aiflow, that jerkyness i prefer letting them land late so unrealistic.
Why microsoft so 1999 do hotfixes its 2023
correct, my time is very limited at the moment so I have to set my priorities, and adding temporary workarounds for “bug-logged and WIP by Asobo” is not very high on that list for now…
Godbless you for your hard work, you make miracles.
Back in Feb 23, 2023
So is there a chance this may be fixed in the next SU in May ?
While I have not seen this discussed or mentioned, from watching the AI Pilot fly MY plane, it “seems” to be doing so in the same way that the Sim flies AI Traffic ?
So, sitting in the cockpit, having the AI pilot fly the plane, you can see more precisely what an AI flown plane does when it is flying. ie you can see RPM, flaps, airspeed, brakes etc etc
Typically, I see it land at greater than a 3 deg glideslope, Not flare (ie smash into the runway), land SHORT, with minimum braking, so takes some time/distance to slow down before it can exit on a taxiway.
It also puts the flaps down WAY TO EARLY, and then limps in at almost stalling speed, for the last 8 odd miles of the approach (Painful to watch)
Also, even if my plane has an IFR flightplan, and the AI pilot is talking to ATC, who is assuing that IFR flight plan, the AI pilot does NOT fly the FP, but rather flies a more direct Departure to Destination direct route, with some correction at the end to land on the runway heading.
If defiantly does not fly the Route as the AP would .
But WHO KNOWS ? There does not appear to be any Asobo documentation to explain how the AI Pilot is meant to fly the plane, so its all ASSUMPTIONS and GUESSES … like so much in MSFS, with it’s lack of any Simulation Operation Documentation. 
The next SU is in August, so 4 months from now.
Do you know why the jerkiness exists or did you just see the jerkiness and decided you don’t like it? Genuinely curious? I’d rather have AI land on the correct runways that they should and actually go and taxi to the gate than the Russian roulette that it is of go around galore. One thing I’d wish they’d really work on is the removed by MSFS engine command that removes aircraft so no reason other than ‘there’s a limit’. Even with reduced object settings it still does it. This was a non issue in the past. Hard to imagine a product in 2020-2023 has more issue than the same general product decades ago.
The current FSLTL injector (Experimental version) seems to have implemented a workaround so that their AI Traffic lands correctly just past the threshold, and with no apparent jerkiness during the final descent phase. I wonder how they do it?
We can still see the aircraft fighting MSFS with some steps up and down…
Same question to you. Do you know why? Have you read any of the documentation?
MSFS doesn’t want them to land at where they’re supposed to, so FSLTL is trying to make the correct glideslope in order for them to land where it’s supposed to, so they’re fighting each other for the correct position(MSFS to land long, FSLTL to land where it should) 
I’ll explain it anyways. For every runway in MSFS there’s a marked landing point either placed or auto generated. Based on where that point is will affect the descent path and distance that an aircraft starts down from the IAF/FAF to the runway. This bug for some reason has caused all those points to be shifted and mirrored to the middle/end of the runway. FSLTL and AIFlow set their own points which is why you have improved landings. That’s only half the battle. The other half is that with MSFS being in control or fighting for control it keeps wanting to put the aircraft back to the altitude needed for the bugged landing points. So the only way to work around that is to keep pushing the aircraft back to the altitude for the correct landing spot. It’s ugly but that’s the only solution. FSLTL may do this more gracefully than AIFlow but they both function on the same principle.
I’m pleasantly surprised. Kudos. Nice to see understanding of why it’s happening instead of just it’s not working. 
Couldn’t somebody with programming expertise simply edit the file or lookup table that contains the incorrect landing-point info, and change them to the correct value?