Perhaps you didn't grasp the core of the problem -- it isn't Ignition, it is the nature of request-response protocols. This problems exists in every product I've ever used over my 30 years in this business, with every brand of PLC and every brand of HMI. If they used a request-response protocol. Serial, ethernet, DH+, Siemens, Modicon, Allen-Bradley, and others. Even tag access over mixed technologies like DeviceNet and ControlNet. Didn't matter. All showed this problem. Products that implement the specific PLC's I/O protocol can be trusted with momentary buttons. Nothing else.
Products like Ignition that consolidate PLC traffic to a gateway, and then all HMI traffic goes through that gateway, do suffer from a higher chance of losing a release event, as there is another link in the communication chain compared to the direct connection of simple HMIs. And yes, there are corner cases that lose a release like closing a window while a button is pressed. But read the documentation for direct HMIs like AB's Panelview -- there are warnings about using momentary buttons over non-deterministic (I/O) protocols.
For an SLC, the only deterministic protocols supported directly are classic AB-RIO, DeviceNet (as an I/O slave, not tag access), and Profibus (the latter via third parties). Use one of those with a direct HMI for absolutely reliable touchscreen pushbuttons. Use a direct ethernet HMI for almost as reliable pushbuttons. Use repeating signalling with corresponding PLC code timeouts with anything else. Ignition or not.
There is nothing for IA to fix in Ignition.