For OTAA, the node knows an end-device identifier (DevEUI), the application identifier (AppEUI), and a secret application key (AppKey), which preferably is unique for every node. That secret is also known to the application server, but not to the other parts of the LoRaWAN infrastructure. So in the end only the application server can allow a node to register itself with a network.
However, the application server might be provided by the same organisation that provides the LoRaWAN network. Like for The Things Network, when not using one’s own application server, TTN’s Console nicely takes care of all that. Now, if you want to register with another LoRaWAN network while the previous network is still operational and its application server is still handling OTAA requests for your node, then the node might indeed (randomly) register with the wrong network.
I guess chances that a previous provider will do this are low. But if you want to be sure then either sign some strong legal agreements, or set up your own application server and don’t share the application secrets with the LoRaWAN provider.
For ABP, the node knows a hardcoded device address (DevAddr), secret network session key (NwkSKey) and secret application session key (AppSKey). If the previous network is willing to forget about those, then you could probably use the same keys with a new LoRaWAN provider, assuming they provide a way to specify one’s own keys. (Which they probably will.) Using just any DevAdrr is not possible, as it includes a network identifier:
The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.
I don’t know if this is really used. (And implementation might differ for different networks.)
TTN has their own id, so cannot support those of others.