@turiphro, what you say is correct - nodes just send data, and gateways will just forward it (possibly filtering based on device address). Only the "network server" behind the gateway can actually decide to accept / reject a packet, based based on the integrity code (which uses the encryption key).
A node using OTAA will send an unencrypted join-request, which will be picked up and forwarded by all gateways. Then, to reply with a valid join-accept message, the netwerk server (or whatever infrastructure is present) will need to know the application key (used only for OTAA, unlike the application session key, which is used to encrypt normal data). So the node doesn't really care what gateway replies, as long as the message is signed with the right key.
In the backend, this will likely mean that if you need your node to work on the KPN network, you'll need to sign an agreement with KPN, and register your node addresses and encryption keys with them (or maybe they have some callback so you can do the encryption yourself, I don't know). If you want to use TTN, you will have to implement the (to be defined) TTN backend protocol so you receive the join-request and can reply with a join-accept.
If you register your node with both networks, then both gateways might reply with a join-accept, and it is up to the node to pick one to use (and the session keys used after OTAA are determined by some data from the join-accept, so if the node picks the accept from one gateway, the network behind the other gateway will no longer be able to talk to the node because it doesn't know the used key).