i can tell you the outcome before even testing it is going to use F11TXXXXM instead.
Yes. I know.
And it may work (or you may be stuck at low brightness if the profile doesn't match your hardware). That particular scenario definitely works on this Kaby Lake system.
I expect that selecting any T profile will work (the generic patch patches all, and all T profiles are present in the injector).
The real question is why you (and others) had a problem with the original patch + kext, which only patched FxxTxxxx *and* only provided FxxTxxxx... (kernel cache issue?)
Update: The profile selected tends to affect... may be hardware/graphics specific! I just tried the FxxTxxxx profile matching on my HD3000 system, and it didn't work correctly... Then I eliminated the FxxTxxxxM profile from the kext... new selected profile is then FxxTxxxxL, which works ok with HD3000.
Update2: Now not so sure... I put the FxxTxxxxM profile back in, then rebooted, expecting to get same failure observed earlier, but it did not materialize. Suspect the previous fail was due to kernel cache issue... or ??? Will do a few more reboots and rebuild caches to see if it is now stable.
Update3: The AppleMaxBacklight value is definitely screwy (seems to be random). May be just temporary instability after making a change. Need to do more reboots to test...
Update4: The FxxTxxxxM profile causes randomness. I switched to plain FxxTxxxx and no more random on my Ivy laptop. Also switched the _UID values to match existing profile usage... will stick with this for a while.
Now more experiments required to discover which profiles are associated with which PWMMax values... You can tell which PWMMax a given profile is associated with by looking at AppleMaxBrightness at PNLF@0 in ioreg after you boot with a configuration that would choose that profile.