I'll just paste the public IRC conversation:

Nov 24 23:44:28 <valhallasw`cloud> twentyafterfour: mm, though it would be in https://github.com/phacility/phabricator/blob/21dca29c5f2929064cfe969cfd4bd417df5621bf/src/applications/project/typeahead/PhabricatorProjectDatasource.php, but apparently not
Nov 24 23:45:58 <valhallasw`cloud> it's parent object https://github.com/phacility/phabricator/blob/21dca29c5f2929064cfe969cfd4bd417df5621bf/src/applications/typeahead/datasource/PhabricatorTypeaheadDatasource.php#L11 has a setLimit, though
Nov 25 01:05:14 <epriestley> twentyafterfour: this is the controlling limit for most typeheads/tokenizers:
Nov 25 01:05:14 <epriestley> https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/externals/javelin/lib/control/typeahead/source/TypeaheadSource.js;37d14a85b38f80e9c0c8b54ef208baffc7b910de$79
Nov 25 01:05:28 <epriestley> There's no way to globally bump it up, though. You could set that to 10 and nearly everything will respect it.
Nov 25 01:05:39 <epriestley> (A few override the default to set a different limit.)
Nov 25 01:11:30 <twentyafterfour> epriestley: Thanks! It's one specific instance that I'm mostly interested in but a global bump might be good
Nov 25 01:13:09 <twentyafterfour> wouldn't there be server-side limit? It doesn't look like the javelin code passes the result count to the server in the request...
Nov 25 01:23:23 <epriestley> I thiink it's derived from that display limit.
Nov 25 01:24:17 <epriestley> (There's also a second limit (which valhallasw`cloud linked earlier) but that's the limit on the number of tokens which are allowed in a field like "Subscribers:" -- some like a task "Assignee" permit only a single user, while others like "Subscribers" allow an unlimited number.)

T3670 is the intended real fix for this problem. I want to do that first and make sure it's still an issue before changing constants.

See also T1906, for possibly adding a more browse/exploration-oriented UI to project selection.

Copying in my downstream comment:

Why are there any non-sanity limits? Why can't we just have a scroll bar?

Why are there any non-sanity limits? Why can't we just have a scroll bar?

Complexity on mobile, tens of thousands of matches for short strings like "e" when selecting users, some cutoff clearly exists where there are too many results to ever be useful (e.g., no one will ever scroll through a thousand results).

In T6634#86052, @epriestley wrote:

Why are there any non-sanity limits? Why can't we just have a scroll bar?

Complexity on mobile, tens of thousands of matches for short strings like "e" when selecting users, some cutoff clearly exists where there are too many results to ever be useful (e.g., no one will ever scroll through a thousand results).

Sorry, I wasn't clear. A sanity limit (e.g. max 100 results or something) is OK, I just think we should be able to select up to that with a scroll bar. Or is that already done but just not shown with the default limit of 5?

We could let you scroll through 100 results, but we'll pursue T3670 and T1906 before considering that. This is not intended as a hierarchical selection UI (T3670 will improve that use case) nor as a browsing UI (T1906 will improve that use case). If those don't address the problem, we could consider adjusting the typeahead.

Empirically, the typeahead is effective on this install for distinguishing between ~30K user accounts without issues, so I believe T3670 and T1906 are much better attacks on the usability issues WMF is encountering.

For what is worth, the top bar search provides 10 suggestions, and even if the items are bigger, it is still manageable on mobile. It doesn't look that having 10 projects suggested in Project fields instead of 5 would cause any problem.

I agree T3670 is the real fix to the problem but, then again, a current default of 10 suggestions wouldn't harm, and would solve a short term problem.

PS: in Wikimedia @valhallasw has shared a workaround for impatient users. :)