Hallo Jonas,
I have worked to address this specific use case.
First, the part of the solution that is already implemented. If you only need to gather metrics in a tenant fashion, you can take a look into this PR:
https://review.opendev.org/#/c/735605/. That pull request enables operators to configure shared traffic labels, and then, these traffic labels will be exposed/published with different granularities. The different granularities are router, tenant, label, router-label, and tenant-label. The complete explanation can be found in the "RST" document that the PR also introduces, where we wrote a complete description of neutron metering, its configs, and usage. You are welcome to review and help us get this PR merged :)
So far, if all you need is to measure the whole traffic, but in different granularities, that PR will probably be enough. On the other hand, if you need to create more complex rules to filter by source/destination IPs, then we need something else. Interestingly enough, we are working towards that. We will extend neutron API, and neutron metering to allow operators to use "remote-ip" and "source-ip" to create metering labels rules.
We also saw the PR that changed the behavior of the "remote-ip" property, and the whole confusion it caused (at least for us). However, instead of proposing to revert it, we are working towards enabling the API to handle "remote-ip" and "source-ip", which will cover the use case of the person that introduced that commit, and many others such as ours and yours (probably).