Stop the press. It has been verified recently, yet in another context scenario, that when one connects the same client output ports to its own input ports directly, with no other connections on input, JACK behaves in an over-optimized mode trick, that I usually call zero-copy buffering. The trick makes the exact and same audio data to appear on both input and output ports. For short, that can be a plausible culprit for the feedback effect you're experiencing, so can blame it on the JACK implementation internals, in this particular and unusual connection situation only. If you just make one single additional connection on input, eg. system playback, besides system capture that is, you may testify that this trouble may get lost, at least not caused by the aforementioned zero-copy effect.
Stop the press. It has been verified recently, yet in another context scenario, that when one connects the same client output ports to its own input ports directly, with no other connections on input, JACK behaves in an over-optimized mode trick, that I usually call zero-copy buffering. The trick makes the exact and same audio data to appear on both input and output ports. For short, that can be a plausible culprit for the feedback effect you're experiencing, so can blame it on the JACK implementation internals, in this particular and unusual connection situation only. If you just make one single additional connection on input, eg. system playback, besides system capture that is, you may testify that this trouble may get lost, at least not caused by the aforementioned zero-copy effect.
Byee