I've since discovered that, if you register a Web Adaptor with the same URL as another, the first WA no longer appears in .../portaladmin/system/webadaptors. The first WA continues to work, at least for the first few hours (i.e. it might stop working later after the security tokens expire?). Regardless, this isn't a good solution because future admins won't see the full picture of WAs at .../portaladmin/system/webadaptors.
My solution was to set the Portal's WebContextURL property (e.g. maps.example.com/portal) and then register the WAs with unique URLs based on their machine names' FQDNs (e.g. web1.example.com/portal and web2.example.com/portal). To do this, for each IIS machine I had to:
- Acquire an SSL certificate for the machine name FQDN (e.g. web1.example.com/portal),
- Bind IIS to that FQDN on HTTPS (in addition to the common web context URL's FQDN),
- Visit the WA config page using that FQDN (e.g. web1.example.com/portal/webadaptor),
- Configure the WA as usual.
Both WAs now appear in the list because they have unique URLs. Even though the WAs are registered with different URLs, they're still accessed using the common web context URL as IIS remains bound to that FQDN as well as the machine's FQDN.
My presumption is that this is because multiple WAs would normally only be used in high availability deployments. In this scenario, all WAs would have unique URLs, and they would sit behind a load balancer using the web context URL. Therefore, all WAs are expected to have unique URLs. A split DNS needs a bit of trickery to get around this because the WAs genuinely share the same URL.