What you describe is standard capability - two triggers, shared sessions on the same queue, concurrently consuming; one continues if the other is disconnected or the instance shuts down etc. So you can definitely do this and it is probably a question of configuration or operation. (FYI the Pub-Sub developer guide is well worth reading for this general area.)
You should check the Broker client prefix ID is the same for each IS in the Broker configuration (it probably is based on your description). You should have one Broker client but it should show two sessions.
You might also want to check how the triggers are behaving - I think originally in v6.5, if you disabled the trigger, especially if the IS was not configured as a genuine cluster, then one IS would unilaterally determine that since the trigger was disabled, the subscription was no longer valid and it would be removed.
This behaviour was updated/patched in the later service packs, but it is important to distinguish between disabling a trigger (turning off the subscription) and suspending a trigger (stopping processing). I believe there also used to be a bug in v6.5 some years back where the handling of multiple instances during shutdown of one or the other would result in temporarily lost subscriptions. Worth checking you are on the latest service pack with fixes relating to triggers.
There are now trigger services to suspend individual triggers on an IS (pub.triggers folder in WmPublic). This is very different from disabling the trigger in Developer and a better method for dynamic suspension of consumption.
#Integration-Server-and-ESB#webMethods