The current mainnet DNS seeds are sort of an issue. The nodes who sit behind these DNS seed servers give no guarantees of switching to the current segwit2x branch.

A p2p network split is almost guaranteed with the situation as it is. SW2x should prepare for this. After a while, the current DNS seeds, assuming they all use the current bitcoin core code, will stop returning addrs for any nodes running segwit2x. After the HF activates, segwit2x nodes will be banned from the legacy network for relaying >1mb blocks. Since there are more frequent disconnections due to bans, the legacy addrman will stop prioritizing sw2x addrs as highly, and maybe drop them altogether.

This same situation applies to the hardcoded mainnet seeds. Assuming the majority do not switch to the segwit2x branch, it could cause similar issues.

This results in a situation where a new segwit2x nodes may not be able to find any compatible peers to connect to initially.

There's probably a couple ways to prepare for this, here's one I'm thinking of:

1. Segwit2x implements a service bit, marking support for segwit2x (make it a high bit, since there's currently a few different proposals competing to use service bit 5/6, I think).
2. Someone willing to run a segwit2x-friendly DNS seed server runs one. This DNS seed server is shipped with the first production release of segwit2x.
3. The DNS seed server responds with all addrs, until the HF occurs, at which time it will only respond with addrs which have the segwit2x service bit.
4. During the interim between segwit and the HF, any volunteer here willing to collect enough segwit2x addrs to create a new hardcoded seed list can do so, which would be shipped with the next release of segwit2x.

As time goes on, this will be less of an issue. But the initial bootstrapping of the p2p network might have to be done this way.