I think this is something that's needed based on the given use case. To achieve this would require a change in how the DB data is stored in the xff_hex column or a change to the DB to allow multiple XFF IPs. The solutions that I see are:

• By some method store multiple XFF IPs in the xff_hex column. However, this makes searching by XFF a more computationally difficult task as the query will require a LIKE query. This would add SQL processing time especially as it would have to include wildcards on both sides. This could be done via a list separated by "|" characters like "|XFF hex 1|XFF hex 2|" with a LIKE query of "%|XFF hex 1|%".
• Add extra columns to the DB to store up to certain number of XFF hexes. This would likely cover most cases of a couple of XFF hexes, but still limits and adds unnecessary columns in most cases.
• Create a new table that stores the hexes for both IPs and XFF IPs (along with possibly other information such as the string representation) which is linked together via a many-to-many relationship to the cu_changes table. This would add two new tables but would move towards solving T305930 (as this would normalise the IP and XFF)