In an URL, the # is called fragment identifier, followed by the actual fragment. It is important to understand that fragments are NOT part of the path in an URL. For example, all the following url's have the same empty path: https://example.com/, https://example.com/#, https://example.com/#whatever, https://example.com/#/login. But each of those URLs have different fragments.

I have no experience with browser extension development or user scripts, though, and the documentation about match patterns is a bit ambiguous in that regard, but i would suspect this being related. The pattern https://example.com/* matches successfully, because it can match against any given path, including an empty path.

However, the pattern https://example.com/#/login would not match against an empty path. I suspect (but i am not sure; again, i have no experience with content script match patterns), that that pattern would match against URLs like https://example.com/%23/login.

Important side note: The URL https://example.com/%23/login is quite different from the URL https://example.com/#/login. I am talking about actual URLs here, i am not talking about URL patterns. Do not make the mistake of treating them as equivalent forms of the same URLs. They are not the same URL.

https://example.com/%23/login is a URL with the path (URL-percent-encoding decoded) "#/login" and no fragment.

On the other hand, https://example.com/#/login is a URL with an empty path and the fragment "/login".

The question then boils down to how could you possibly match against a given fragment in a URL. Frankly and unfortunately, i don't know. Content script match patterns basically can match schemes, hosts, and paths (https://developer.chrome.com/docs/extensions/mv3/match_patterns/). Note that it does not include fragments.

Whether you can reach your goal while still employing content script match patterns by choosing a different angle or different approach that would not need to rely on matching against URL fragments -- again, i don't know...

Whether TamperMonkey offers alternative mechanisms for fragment matching, i don't know. But even if it would have such a mechanism, I would have a hard time understanding how this could possibly work satisfactorily. Navigation based on URL fragment where the scheme/host/path of the URLs stays the same would not result in page unloading and loading. It would just result in the page repositioning in the view port. How this could possibly work with page-based user scripts (whose life-time and scope are normally both bounded by the page loading and unloading), i have frankly not the faintest clue...