No, the router sends the replies on behalf of your clients in this configuration. There is no possibility for Pi-hole to see who the original requestor was. Hence, they are one and the same client.
IP address. DNS queries are asked using either the UDP or TCP protocols. Both use IP addresses for describing the source and destination of the packages. Hence, IP addresses are the only thing visible to the DNS server.
We can source hardware addresses (using other means) for devices not more than one hop away (this is what the network overview table does). It is not possible to get the hardware address for devices connected through routers, VPNs or other separations (like VLANs). Hence, hardware addresses don't seem suitable for this task.
We implement subnetting support (your client can be 192.168.3.0/24 to match all 192.168.3.1 - 192.168.3.254). This allows a certain flexibility, e.g., other blocking rules in a "guests" network. This would be impossible with hardware addresses as identifiers.
From a technical point of view, I say: Your DHCP shouldn't do that. I know that many (esp. the cheaper) routers do such things. We call this non-deterministic. There isn't much we can so about it, the group management, currently, cannot auto-adapt, also, because often enough the devices are out of view. For instance, guest networks are often separated and their hardware addresses are not visible to Pi-hole.
However, we're open for discussions on improving Pi-hole if you have a good idea. We can maybe allow both: IP addresses (with possible CIDR modifier for subnet description) and hardware addresses. This will be complex and maybe even harder to explain to users.