If you don't want to help people understand things like this, which is fine, it would be better to suggest other good resources for learning. There's nothing wrong with people asking questions, or being confused, on this forum.
The fact that web PKI certificates are independent and don't contradict or invalidate one another (or that they have semantics of "this is a valid key for this subject" rather than "this is the valid key for this subject") is a design decision for the web PKI rather than a consequence of "how encryption works". You could imagine a system where there can only be one valid certificate for a particular subject entity at a time; it would just make (very) different tradeoffs from the system we ended up with for the web.
@gschmidt, @rg305's post #2 is making the valid and helpful observation that there are many different possible ways to set up a configuration where multiple devices share a single public IP address. Some of those ways involve having a single certificate on a single device, some involve having multiple copies of the same certificates on multiple devices, and some involve having separate certificates for the same domain name on different devices, with different cryptographic keys. None of these is more correct or valid than another (although some involve different trust relationships between the different devices that make up your network, so they could be said to manage risk differently). Some of these might be much easier to set up with particular devices and software, compared to others. In all cases, you are allowed to have more than one valid certificate for a given domain name at a given time, but whether this is desirable depends on how you want to set up your network.
When a browser makes an encrypted connection over the network, there is a cryptographic "other side" in the connection which presents the certificate and possesses the corresponding private key. This is almost always a single server machine, although there are advanced configurations (not relevant to your home network!) involving content-delivery networks, or censorship circumvention technologies, where it might involve several different machines.
The server device that is the cryptographic counterpart to the web browser is said to "terminate" the TLS session. Depending on how it's set up, it might then act as a proxy in order to forward the connection to one or more other devices. This behavior might or might not be visible from outside your network.
If you want to terminate TLS on the pfSense device, it would need to act as a proxy (in this configuration, known as a "reverse proxy") to forward web requests to the internal devices. This part does not necessarily need to be done over TLS, and the pfSense device could differentiate where a given connection is forwarded either using different URL path mappings or different port numbers. Alternatively, you could use transport-layer port forwarding to the two different Pi devices, in which case the pfSense device would not terminate TLS, and therefore the Pi devices would do so themselves (therefore needing certificates of their own, or their own copies of the same certificate).