You can configure multiple listeners but what I think you want to do is just configure the other IP (for the 3rd replica) at the cluster level so that your AG resource can access it. If your cluster is configured for the multi-subnet then you should have the ability to add the IP for that 3rd replica to your current listener.
If I recall you might have to create the role in the WSFC for your listener as a client access point. I know this is the required configuration when I have built AGs in Azure environments, but those may be special circumstances compared to dealing with all on-premise setups.
Does the Windows Failover Cluster for a multi-subnet SQL Server
Availability Group require a static IP entry for each subnet?
The CNO will require an IP address for every subnet it could reside in.
I am running SQL Server 2012 on Windows Server 2012 Hyper V VMs in 2
separate subnets in the same domain. I understand that I will need an
IP from each subnet when I create the listener for my AAG. What I am
unclear on is the configuration of IPs on the underlying Windows
Failover Cluster.
For the underlying WSFC you'll need at a minimum:
Node1 - IP Address for each unique subnet for each network interface
Node2 - IP Address for each unique subnet for each network interface
CNO - IP Address for each unique subnet
EX: 2 nodes, 2 subnets, 1 interface per node, subnets 192.168.1.1/24 and 192.168.2.1/24
Node1: 192.168.1.10
Node2: 192.168.2.10
CNO: 192.168.1.20, 192.168.2.20
Also, if the server hosting the secondary replica does require its own
IP, does it also require its own unique cluster name (and can you
explain why this is necessary)?
I'm not sure I understand this part of the question. All of the resources can only belong to a single cluster - there is no cluster inside of a cluster thing.
Edit - I looked at the link that you posted and I'm not sure why the author stated "•Cluster name for each node". My only guess is they meant each node needs a name and IP (for the node). Otherwise it's not a correct statement, the author should probably be contacted.
Best Answer
Please see No such thing as a Heartbeat Network and Everything You Know About Clustering is Wrong. These don't really answer your question, but perhaps will change the question to, "Do we need a heartbeat network?"
With Windows 2008 and later, a heartbeat network is not required, and it's really only going to benefit if your "public" network gets so saturated that cluster communications are delayed, in which case the "heartbeat" network may stop a failover from occurring (ref. Shanky's comment below). This was a nice safeguard that made more sense in the days of 10/100 Mbs networks, and although it's certainly possible to saturate a 10 Gps link, it's far less likely. I.e., if you anticipate having major issues with your public network, then a private network might ease some of the pain, but you'll still need to address the public network issues to cure the disease.
Additionally, the use of file witness and majority node quorum features additionally reduces the need for a private network for cluster stability. Many clusters for availability groups now span geographic regions where it doesn't make sense to bridge your network just for the purpose of putting the DR node on the same subnet. Again--if it added a huge amount of value, it might make sense, but the benefit just isn't there.
The monitoring built-in to availability groups can initiate failover even if the cluster doesn't detect any problem, and I don't think it would care about a private network as it would only care about the route it is using for replication. Hopefully someone can post a reference to how AGs might benefit, or not, from a private network in different scenarios, but I'm guessing that it doesn't exist because the private network has not been required for 10 years now.
If you think that the replication of the database will put significant load on the public network, you can use a private network for the replication by setting the endpoints to the private addresses. See Configuring a Dedicated Network for SQL Server Always On Availability Groups Data Replication Traffic. Yes, I know there is a link in the article to a previous article advocating a private network. My point is that if your public network is so bad that you need a private network, you are probably going to have a lot of failovers and other issues. It's like buying insurance for a leaky boat--great, you've got insurance, but the boat is still going to sink.