What they should do, and what they will do, are two totally separate things. As it is with so many other software companies.
Support is different than enhance. Either way I think its pretty clear that this issue was solved (or rather will be solved) in a future release.
If you think you need it in a different version I would recommend you open a ticket and ask for a retrofix and go through that channel I suspect if enough people request the retro for the same version it might be worth it.
The problem is that this fix requires a change to one of the most fundamental aspects of Epicor as a whole and that is the Client->Server communication protocol so I would be hesitant to deploy a bunch of changes on all sorts of older versions without proper testing which is really hard to justify when you have that invested already in a future release.
While we donāt like it (I donāt like it either) the answer for this one is likely , upgrade.
Ya, Iām going to wait to upgrade. Iāve had too many responses stating āplanned for future releaseā, where it was a change to an adapter or a service. I feel like during this Kinetic conversion they are not back porting as a rule.
It is hard to maintain software at wildly different versions I get itā¦ its a tough call even Microsoft eventually had to to give up on that.
By the way I have been running compressed with the unpatched version in Production since I started this post and while sometimes it does cause the client to glitch out, the performance benefits still outweigh that sporadic issue. It tends to only glitch out on REALLY heavily active screens or processes though your mileage will vary may be worth a shot.
The only thing we did have to do was spin out an uncompressed version JUST for the Task Agent because that client moves really really fast and was glitching out too quickly.
Our current setup is
TaskAgent ā Uncompressed App Server Instance
WorkStation Clients ā Compressed App Server
My client glitches out about once every week or two but its well worth it, though I am waiting with bated breath for 2023.1.15
Since this is a .NET Framework issue, where possible, see if you can use the browser? 
How can you tell if your environment has this fix or not?
If you are in the latest version on cloud you have it. You can check by loooking at your web config
You can also use something like fiddler classic to see if the traffic is zipped
Darn, I was hoping this would finally be a solution for the spinning wheel of death but its still happening on Pilot.
Is spinning wheel shown in browser? If yes, then compression in smart client is not related to it anyway.
No its in the client.
So it is important to upgrade to 2023.2 to get good performance?
Sounds like 2022.2.30 would be affected?
Weāve been doing ok, but also was used to 2021.1.30 for the longest time.
hmmā¦
Not really sure how to test this.
One other thing to be aware of is the DynamicCompressionDisableCpuUsage parameter in IIS. This, if exceeded for 30s, disables compression (until the DynamicCompressionEnableCpuUsage threshold has been triggered).
According to the Microsoft docs, the default for this is 90%, but every Epicor server I have looked at has this set to 70%. So while the rest of the settings may be correct, if your server is particularly busy, then maybe compression isnāt working.
The best way I can think of to validate is in the IIS Logging adding a custom field on Response Header - Content-Encoding. This should give you g-zip for all logged requests over 2700b (sc-bytes can be added to see the size of the response).