I don't believe there's a problem on the hardware level, and that would mean: no replacement program. They need to fix it on the OS or firmware level. But I agree with iMacDragon that this is a complex beast: Apple don't know how to handle this thing yet, so users have to be very careful & restrictive, at least for the time being.
Noticed one thing today: I had written before that changing the power management settings made all the bridgeOS panics at wake-from-sleep or during sleep go away. This morning, though, the 2018 i9 MBP woke from hibernation (safe sleep) with the lid still closed, but only when I inserted the USB-C charging cable, even though I had set acwake to 0 with pmset.
So it seems like there's something wrong with the interplay between the T2 and the SMC, meaning for example that the computer forgets certain power management settings in sleep or safe sleep. Just my 2¢.
Yes, the communication between the T2 and the CPU might be a complex beast that could explain why there's such a diverse frequency of the problem across users. Of course it could also be hardware, but, if it was hardware, they would have known, at the very least by end of August, that there were faulty chips, they would have located them, and all MBPs assembled it September would be fine, but some users report seeing the problem in recently assembled MBPs, so this fact would point in the direction that it isn't hardware (my MBP was assembled after Sept 14, and I didn't get any KPs yet, though).
I remember for example the case of the G5 iMac and the infamous faulty capacitors: Apple realized about the faulty capacitors very soon, and they reacted by obviously assembling the next batches with other capacitors. In this case, if it was hardware, I assume Apple would have reacted in a similar way, and all MBPs with KPs would have been assembled within a limited range of weeks.
Of course there are other types of hardware failures which are harder to diagnose: The Silicon Graphics Indigo2 IMPACT with TRAM modules comes to mind: there was a X server crash that happened when the texture RAM (TRAM) modules were faulty, but there were also reports telling that the same crash happened in machines with good TRAMs... at the end it was very hard to affirm the real cause, but the most accepted cause was that TRAMs used to get really hot (to the point that some of them were actually fried), and perhaps such a high temperature caused the X server crash in some TRAM modules and not in others. I really hope the 2018 MBP KPs issue is different from this, because that TRAMs episode is one of the most frustrating moments I remember as a computer user (ie: you never knew if the new Indigo2 you had was going to suffer this problem or not, and when you got a X server crash but you realized that the TRAMs still functioned after the crash --because textured gfx continued to work--, then you were puzzled, disappointed, and without a clue on what to do).
However, if at some point we can affirm that MBPs assembled later than some date are no longer getting KPs, then it's obviously hardware. Otherwise, it's either software or a SGI TRAMs-like issue in the lines of "it's hardware but nobody really knows why some units fail and others don't" (and let's hope it's not this scenario).