Тут в твоей логике пробоина: отсутствие чего-либо не доказывает его невозможность

а теоретическая возможность и реальность - это разные вещи

когда-то в 500 г. до н.э:
- Земля круглая! Вот смотри я доказал.
- Нет не круглая.
- Почему?
- Не было еще в истории случая чтобы доказали что земля круглая.

и  критикой PR люди требуют от реального кода теоретически возможных свойств

Есть список аргументов. Из него нужно несколько раз сделать следующее:
1. Попнуть первый элемент
2. Вернуть ошибку, если его нет
3. (опционально) проверить kind и вытащить из него внутреннее значение. Вернуть ошибку, если kind неправильный.
4. Положить в переменную.
После того, как все аргументы обработаны, либо:
1. Оставить остаток как есть
либо
2. Проверить, что он пустой, вернуть ошибку, если нет
в зависимости от конкретного применения

Ну т.е. ты мне пытался доказать совершенно другое

Ладно, что я своё время трачу впустую

я не пытаюсь ничего доказать, я критикую критику, возможно даже аргументированно.

это называется парсинг и решается комбинаторными парсерами

то есть тебе нужно сделать комбинаторы аля:

let (foo, list) = get_value(list)?;
let (bar, list) = get_inner::<Integer>(list)?;

Я посмотрю, сумеет ли nom пережить настолько нестандартный входной тип, но, по-моему, нет.

выплескиваю накопления негативных эмоций к критикующим, надо лечиться

Пилить свой фреймворк для комбинаторных парсеров не входит в мою задачу.

А, ну тут можно индукцию на гетерогенных списках, думаю. Ну у тебя два варианта: макросы или индукция. Яб индукцию выбрал, т.к. тело макросов трудно разбирать, трудно понять что они вообще делают. Можешь посмотреть пример в demux-stream

Я хочу обойтись без макросов в типах, спасибо.

Привет, Hlist!(), привет, Coprod!()

Не за что)

Скорее уж действительно посмотрю в сторону nom::sequence::tuple. Там уже написан макрос, генерирующий растовый бойлерплейт.

Доги, а ты бы индукцию или макросы выбрал?

impl List for <все туплы>, который позволяет работать с туплами разной длины