Show login items only on a subdomain level and based on path

Hi @Joy_1P
Thanks for your response to my request.
I would appreciate if you are forwarding this issue for further discussion, especially as it seems this issue has been on the table years ago, but not considered anymore.
The community page you have linked to explains only roughly what the limitations are.
However, from this answer I do not really get what the problem really is.

Sure, you have to keep simplicity in mind when designing the user interface option for allowing more advanced users to enable subdomain, port or path matching.
But I think these additional 3 options could be added for selection after having entered a website.

Second, I do not get the problem from a technical perspective.
I understand that the item data is encrypted and you are storing the root domain name and hostname of website URLs as hashes already to allow for a fast lookup via these hashes and without the need to decrypt every item to find out whether an item should be displayed on a website.
But, why are you not simply also creating hashes of the combination of subdomain + root domain of the url, or of domain + port, or domain + first value of the URL path?
Storing additional hashes for an item does not seem so difficult.
You also just have to compare additional hashes, which will not introduce much more overhead.
1password could also store in it’s database which matching types are desired by a user based on all user items and so 1password can create additional hashes (e.g. domain + port) when a user visits a website for comparison with stored hashes, but only creating hashes of those url component parts which are also part of the user’s items to reduce the overhead – if necessary.
And if some non-advanced users do not use matching at subdomain, or port or first-path-element level, 1password may store that in its data structure and refrain from attempting these additional „advanced“ matching all together and hence, no additional overhead of hashing and comparing is introduced.

What do you think about that?
Do you see any shortcomings of this approach except for adding a bit more complexity?
At least based on the short blog discussion you shared, my suggestion is implementable and realistic to offer.

Thanks for your response.
All the best!