Because std::match_results holds std::sub_matches, each of which is a pair of iterators into the original character sequence that was matched, it's undefined behavior to examine std::match_results if the original character sequence was destroyed or iterators to it were invalidated for other reasons.

Покуда жива строка, по которой искали, можно обращаться к результатам.

Т.е. ссылку хранить можно, но нужно следить за временем жизни оригинальной строки.

Естественно, если это был std::string, то не должно быть переаллокаций. Т.е. зарезервированный размер строки не должен увеличиваться.

В этой строчке всего лишь говорится что нельзя разрушать оригинальную строку.

auto &ref = result.cbegin();

Вот это называется «Reference Lifetime Extension». Вполне себе валидная практика. Только смотри, чтоб ссылка не пережила сам result и то, на что он ссылается (т.е. изначальная строка):

Because std::match_results holds std::sub_matches, each of which is a pair of iterators into the original character sequence that was matched, it’s undefined behavior to examine std::match_results if the original character sequence was destroyed or iterators to it were invalidated for other reasons.

cbegin() возвращает const_iterator, поэтому не понятно, зачем тут хранить ссылку на итератор, вместо самого итератора…

auto &ref = result.cbegin();
// вместо
auto iter = result.cbegin();

Сначала не понял, причем тут «Reference Lifetime Extension», думал возвращается ссылка. Но тут зачем-то сохраняют ссылку на итератор, который становится временным объектом, чье время жизни продлевается ссылкой, вместо хранения итератора напрямую.

У меня в коде примера ошибка, исправил.

хранить можно

до вызова деструктора result