First, if you want to log transactions between SlickEdit and GDB, just turn on def_debug_logging, as has been discussed before here on the forum.
Normally (local debugging), we find the child process running under GDB and send a break to it. The program that you inserted between SlickEdit and GDB is causing us to follow what would otherwise be an impossible code path (remote debugging, but GDB has a child process). I am putting a fix into the next release so that we will not be fooled so easy, but that is a separate issue.
With remote debugging, to cause a suspend, we found the only way was to put a proxy between GDB and the remote debug server, we then send a message to the proxy which in turn sends a break command to the remote server, and then we get a stop event if everything goes correctly. You may need to verify that your remote gdbserver expects the same command to suspend as the standard linux gdbserver.
Why don't we send a "-gdb-interrupt" command to GDB instead of all this garbage? Well, because "-gdb-interrupt" wasn't implemented initially with GDB/MI. And secondly because GDB/MI, even in remote debugging mode, did not properly support asynchronous commands. Recent release notes suggest that the async mode has been finally implemented as of GDB 6.8, but we have not had the opportunity to test it, and, in addition we still need to work with older versions of GDB.