Girl #2

That's how I usually find them, i.e., search on title; click 'Exact matches' on the resulting list of titles; then 'ctl-F Short' to expose the Shorts in the list. The only difference is that I cut & paste initially instead of type since it's more accurate that typing (no typos). Was that my mistake? 

Now I wonder my find resolved with a space (and took my # for something else):

%20 is the URL encoding for a space character, used in web addresses (URLs) because spaces aren't allowed, representing the ASCII value 32 as two hexadecimal digits (20) and ensuring links remain functional, often appearing in file names or search queries with spaces.  

And your resolved correctly with " #2":

"%20%232" is URL-encoded for " #2" and refers to various things like Cardone Power Steering Pump 20-232, a specific Virginia Code section (20-23) for ministers, or even Section 232 of US Trade Law, depending on the context; it's a common pattern for part numbers or legal/regulatory references. Without more context, it's likely related to an automotive part or a legal citation. 

Given that, I wonder further what would have happened if the title had been "Girl #3"

I tried it again by typing instead of pasting the title. Got the same result. (https://www.imdb.com/find/?q=girl%20&s=tt&exact=true&ref_=fn_ttl_ex) 

Are you still using a U.K. keyboard? I switched from my normal U.S. keyboard to the U.K. keyboard and finally got it: https://www.imdb.com/find/?q=girl%20%232&s=tt&exact=true&ref_=fn_ttl_ex 

What does this tell you about IMDb's search engine? That it's language- or keyboard-dependent? I wonder if there's some kind of bypass or correction around this problem that IMDb could make? Not all users would think of this alternate search method of changing keyboards to "correct" this problem. 

Hi Hallmarkie -

Thanks for taking the time sharing your observations.

From our testing, the # symbol is handled consistently across keyboards and is always encoded the same way behind the scenes.  We haven’t been able to reproduce the exact behavior you’re seeing using standard inputs, which makes it difficult to pinpoint the cause.

One possibility is that, in some cases, applications can use visually similar characters that aren’t the standard # symbol (for example, characters used in certain fonts or languages).  If one of these is copied and pasted, it may look correct but behave differently during search.

If you’re able to share exact steps to reproduce the issue (or a linked short screen recording showing the behavior), I'm happy to pass along the information to our tech team to review and determine whether there’s an opportunity to improve the search experience. 

In the meantime, we appreciate you flagging this.