1) Проверил у себя, да, в те 3 location, в которые поступали запросы с дальнейшим перенаправлением в memcached, имеются директивы из headers-more-nginx-module.
Попробую выполнить запросы на эти location с отрубанием memcached по kill -11

2) Спасибо за ссылки, тоже обратил внимание
FAILED
./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module
--add-module=..
--add-module=../echo-nginx-module
--add-module=../lua-nginx-module
--add-module=../nginx-eval-module

PASSED
./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module
--add-module=../nginx-eval-module
--add-module=../lua-nginx-module
--add-module=../echo-nginx-module
--add-module=..
> build.log 2>&1 || (cat build.log && exit 1)

not ok 73 - TEST 12: set multi-value header to a single value - response_body - response is expected (req 0)

интересно, какой случай этот тест проверяет ?
Когда в результате указанных директив nginx должен вернуть больше 1 header с идентичным ключом, но разным значением ?
Например:
Content-Type: application/javascript
Content-Type: application/json
?
3) тестирование - вещь добрая и нужная, только есть 2 основные версии и куча минорных для наших клиентов, клиентов по обе стороны немало, в каждой версии есть разного объема правки в файлах конфигурации nginx. Чтобы по феншую провести, нужно создать окружение как у клиента, желательно такую же машину, но нагрузку нереально достоверно точно сымулировать, в лучшем случае jMeter-ом записать что есть, что стало. И если делать максимально правильно, то может занять немало времени, а т.к., видимо, у клиентов есть проблемы, но продолжают есть кактусы, то начальство не очень заинтересовано в трате времени на разворачивание стенда (-ов если логику с comet проверять) для проверки старых версий.