Полный перечень зарезервированных символов (все они могут выступать в качестве разделителей):
:/?#[]@!$&'()*+,;=
Эти символы нельзя заменять на их коды и наоборот, иначе можем получить совершенно другой URL.
Кстати, кто-нибудь знает, есть ли какие-либо стандарты на повторное кодирование символов в URL?
Повторное кодирование не допускается. Выражение типа %2525 может иметь место, если задать, к примеру в Яндексе поиск строки "%25". Здесь тоже кодирование одно и не "наслаивается".

Если задать  в google поисковую строку "%C2%A0", то получим первый из указанных URL. Здесь %C2%A0 совершенно справедливо воспринимается как строка, а не как закодированные данные.
Остальные URL-ы нерабочие (по крайней мере у меня в Опере).

Всех их объединяет одно - кодируется текстовый параметр (строка). Попробуй зайти на URL http://www.gg2.net/upload/Bill%2520Gates.jpg из первого примера - не получится. Когда речь идет о строке, обработчик воспринимает %20 не как код, а как осмысленное сочетание символов. В свою очередь, если любой URL из приведенных будет передаваться в качестве текстового параметра скрипта еще кому-нибудь, получим значения типа %252520.
А вот происхождение в твоем кэше URL
http://ru.wikipedia.org/wiki/%25D0%25AD%25D0%25BC%25D0%25B8%25D1%2580_%25D0%259A%25D1%2583%25D1%2581%25D1%2582%25D1%2583%25D1%2580%25D0%25B8%25D1%2586%25D0%25B0
интересно. Могу предположить, что он образовался также из текстового параметра скрипта при помощи списка "Переадресация" путем отсечения "вызывающего" URL.
С учетом всего этого, правило, преобразующее код типа %2525 в %25, на мой взгляд, лучше не использовать.

Тут ты немного нарушил логику: из того, что закодированный повторно URL обрабатывается неправильно не следует, что противоположная ситуация - когда декодированный URL находится в виде параметра скрипта на месте закодированного - тоже будет обрабатываться неверно!
Попробуй зайти по ссылке:
http://tbn0.google.com/images?q=tbn:P4qJidTTzOytPM:http://www.gg2.net/upload/Bill%20Gates.jpg
- она обрабатывается сервером нормально, хоть я и декодировал знак процента!

С примером согласен, но не слишком ли он искусственен? Кому придёт в голову искать "%45" - тем более, что при таком поиске Google отбрасывает знак % - и ищет вхождения "45"? Не единственный ли это случай, когда такое может происходить?
Думаю, здесь ты прав! На RU-Board как-то обсуждалась ситуация, когда это правило неправильно работало, если знак двоеточия закодирован. В той ситуации оно всё же должно было сработать, поэтому я доработал это правило так:
#5#~#True#~#.+&(url|go)=http(:|%3a)//#~#http://#~#False#~#True
#5#~#True#~#.+/go.php\?http(:|%3a)//#~#http://#~#False#~#True
Такие правила правильно сработают в описанной тобой ситуации. Хотя, если честно, они кажутся мне наименее полезными и наиболее сомнительными из всех правил по умолчанию. Пока глюков не замечал - поэтому держу их включёнными! Попаданий довольно мало.

Отлично! Со всем согласен, только не совсем понял, какой бывает <конец>  в
site.ru:XXXX<конец>
(www.)site.ru<конец>
site.ru:<конец>

Теперь понятно. Только обнаружил одно НО: отбрасывать http:// надо после Переадресации, чтобы сохранялась возможность переадресовывать на другой протокол (например, FTP://) Насколько я понимаю, именно для этого автор и не стал отбрасывать http:// в Переадресации.
Хотя можно и иначе: отбрасывать ДО Переадресации, но, чтобы можно было перенаправить на другой протокол, в Переадресации (в обоих полях: Правило и Замена) делать проверку на наличие отличного от HHTP протокола (чтобы не быть ошибочно переадресованным на http://ftp://site.ru). Например, можно легко отловить название протокола правилом (RegExp):
^\w+://
При условии, что FixURL уже применён, такое простое правило безошибочно отловит все ссылки на другой протокол! И не поймает ничего лишнего!
Думаю, второй вариант даже предпочтительнее первого (который реализован в текущей версии HC).

Только после Переадресации... См. мой предыдущий пост... Причём всё, что там написано, относится и к www. перед именем хоста! Иногда важно переадресовывать ссылки с www. на адреса без него! И наоборот! Это действительно важно! Иногда сайт существует в двух видах: c www. и без него! И когда залогинивешься на сайте без www., оказывается, что на его варианте с www. ты не залогинен! Единственный способ обойти этот глюк - использовать Переадресацию! Что я и делаю! Поэтому ДО Переадресации нельзя отбрасывать ни то, ни другое! Ни в коем случае!

....С остальным полностью согласен!

Наконец-то в этой теме слышу высказывание в пользу ясности и здорового вкуса!

Спасибо!

Это те символы, которые как ни меняй их на коды и обратно - получим полностью эквивалентный URL, и запрос будет гарантированно отправлен туда же и с теми же параметрами и так же понят сервером. Потому и в FixURL гарантированно можно заменять коды только этих символов, а все остальное будет при необходимости заменять URL2FileName.
А если правило в Переадресации прописывать криво, то и сейчас не попадем по желанному адресу (но я не думаю, что ты это имел ввиду).
Если же я чего не так понял, приведи, плиз, пример.

Теперь про хттп://. Если я правильно представляю, оно отбрасывается и сейчас при проверке любого списка, кроме Переадресации. Хотя на практике с такой необходимостью я не встречался, но смысл оставления http:// для Переадресации теоретически может иметь место. Пусть так все и останется в отношении отрезания http://. Т.е. до проверки всех списков нормализуем URL с помощью процедуры FixURL без отрезания http://. "Переадресации" отдаем этот нормализованный URL, а остальным спискам - его же без ведущего http://.

Только вот непонятно при всем этом еще одно: если список "Переадресация" чувствителен к http://, то как может быть нечувствителен к нему Белый список, в котором мы прописываем исключения для "Переадресации"? Имхо, это недоработка.