Hard to tell what is causing the issue, but some considerations for your troubleshooting:
if you are to move to a middleware software like flrig or omnirig, the main software should not reference Digirig’s COM port anywhere in its configuration - neither rig control nor PTT. The PTT should be set to CAT in this case. Once one app accesses the port for any reason the other app will not be allowed to touch it
if testing CAT control, do it with frequency sync in each direction while in receive mode. If using PTT for testing, another factor that may be at play is RFI and it will be hard to tell if you get error due to the issue with the normal communication or if it’s RFI wrecking havoc on it
I did attempt to use both FLrig and Omnirig but because I run an arch linux build I’ll have to mess around with wine for a bit until I can get omnirig to work, and FLrig seems to always throw a transceiver not responding error. What is odd about FLrig is that sometimes when it claims that the transceiver is not responding, is that I can still set the frequency on the VFO even though it doesnt have a proper connection? Like I can change a value in FLrig and the change will show up on the TS-870, but the connection isn’t properly opened. I can see if its an RFI issue, I do have a spare toroid lying around from when I had USB RFI, so I could wrap the coiled serial cable around that and give that a shot. I’ll post my results here.
Too many things to troubleshoot. When experiencing issues my recommendation is to simplify things to the pint of the system working and then adding complicating factors one-at-a-time. In your case I’d first try on PC before moving to Linux. Later when/if that works, you’ll know not to worry about the hardware issues (cables, RFI etc) and focus on the Linux software setup.