This has been discussed before back in February, but the discussion tends to get super technical.
Basically, you can’t think of thread the way you think of Wi-Fi or Zigbee when it comes to the names of networks. It’s just a different architecture. Thread does a lot of stuff at a layer above Where Zigbee and Wi-Fi do it.
I have a friend who calls thread a “mosaic of tiny mesh networks that share a security key” and I think that’s a pretty good way to think about it visually.
Each thread “partition“ can be on a different frequency. Then a thread border router will pass messages between the different partitions by going over the Wi-Fi and back again. Which sounds ugly but actually works pretty well.
And thread is great at frequency agility, much better than Zigbee in most implementations. It can change the thread frequency on the fly very quickly, if needed. But that’s usually done to avoid Wi-Fi interference, not for normal routing.
But mostly once you get to Thread 1.3 the message hits a thread border router, that TBR uses Wi-Fi to get to a TBR on a different partition, and then that second TBR reaches the next set of thread devices.
Also, the partitions get reformed fairly often. You might see one set of “networks” listed on Monday and a different set listed on Tuesday, and it wouldn’t mean anything good or bad. Just that partitions had been re-formed due to local traffic. (a lot of app UIs don’t know how to handle reporting the thread partition stuff.)
It’s part of the “hubless“ concept. There’s no single primary coordinator, so it doesn’t matter if they show up as different “networks.“ They should all still be able to talk to each other. Remember that each end device has its own unique IP address, so the coordinator doesn’t have to keep all of that straight.
All of which is to say, I don’t think it should matter if the app says you have a bunch of different thread networks As long as there are thread border routers to connect them.
But all of that only becomes true with thread 1.3. The older Thread generations aren’t as good at passing stuff between TBRs, if they even do it at all. So that’s a whole separate issue than the fact that you’re seeing multiple “network” entries. 
(Having said all of that, that’s what’s actually happening at the transport level. But the Thread group has decided to use the term “one thread network” in a way which sort of ignores the fact that the partitions exist. I think that’s a marketing decision, to be honest. They don’t want thread to seem too complicated. The problem is that a lot of the UI’s haven’t kept up. They see different frequencies and assume it’s different networks, which it is from one perspective but not for the way the thread group wants us to look at it. The thread group is basing “Network“ on a shared security key, so the fact that parts of it are on different frequencies, or changing frequencies, doesn’t matter.)
Here’s my previous post on the topic. It includes a bunch of links to technical references if anybody’s interested in a deeper dive.