No need to apologize for your questions, it’s a legit one. 
If I understand your question correctly, you are asking whether two ECDSA signing subnets can produce ECDSA signatures at the same time, correct?
In the current setup, we envision that we have a single active ECDSA signing subnet, which will be a 34-node subnet (for the production release) that is still to be created. Let’s call it A for “active” subnet. The NNS will act as a key backup subnet. Let’s call it B for “backup” subnet. Under normal operation, all signing requests will be routed to the signing subnet A. B just passively holds the ECDSA private key for reasons of backup (key availability).
Let’s assume that one or a few nodes in subnet A fail, which is the likely failure scenario. Then A can still continue producing threshold ECDSA signatures as our protocol can handle failed nodes. Assume the case of A failing completely. Then we would currently likely not switch signing to B (the NNS) as threshold ECDSA is very heavy on CPU and this could negatively affect the NNS. We would either repair A or deploy a new signing subnet A’ and recover the threshold ECDSA private key from B (NNS) to A or A’.
The approach we have is largely compatible with having multiple active signing subnets, if this is required in the future for scaling out. In order to deploy this functionality, we would mainly need to implement deterministic load balancing on the message routing layer to load balance the signing requests to multiple signing subnets.
Hope that answers your question about multiple signing subnets.