Path cache won't always contain the canonical alias, depending on order of calls to drupal_lookup_path()

It's possible to pollute the path mapping cache via calls to drupal_lookup_path().

Calling drupal_lookup_path('source', $alias) with a wrongly-cased $alias will result in the path cache containing the wrongly-cased alias. However, the very first time drupal_lookup_path('alias', $path) is called the path mapping cache gets completely destroyed and rebuilt; this time with the correctly-cased aliases, so the bad cache doesn't really hurt us as long as the calls are made in that order. However, if drupal_lookup_path('source', $alias) is called with a wrongly-cased $alias *after* drupal_lookup_path('alias', $path) is called then it will fail to find any matching entry in the cache (due to the case-sensitive array_search comparison) and it will end up polluting the cache with the wrongly-cased entry which will never get fixed.

Specifically, I saw this as a result of the interaction of some contrib modules. Global Redirect couldn't retrieve the correctly-cased version of the alias without clearing the path cache. See a few related issues where this problem has arisen:
#2048137: Canonical redirect breaks path cache →
#2400521: Breaks path cache →
#1983954: Case Sensitive URL Checking does not works when enable both boost and redirect →

To reproduce:

1. Shield and Global Redirect modules installed
2. Configured Global Redirect to redirect all requests to the correctly-cased version of an alias
3. Have an alias content/test
4. Attempt to access content/tESt
5. Page loads at content/tESt without redirecting me to the correct path (content/test)