Здравствуйте, vdimas, Вы писали:

V>Ну... там завязка не столько на устройство, сколько на имеющуюся функциональность вокруг такого устройства, включая парсинг и сериализацию банальных чисел и дат.

V>На сегодняшний день целиком и полностью доступна аналогичная функциональность поверх строк Span<> как узких UTF8, так и последовательности широких 16 битных char.
V>Эта функциональность раскидана по АПИ дотнета:
V>Но у себя, например, собираю требуемую функциональность "в одну точку" через "инлайные" статические классы-хелперы.
В этом толку нет, т.к. все эти Span<char> и Span<byte> всё ещё требуют непрерывный блок памяти.
Для того, чтобы внедрять "альтернативные строки", нужно переписывать алгоритмы не на Span, а на IReadOnlySequence.
То есть то, что пилится сейчас, помогает для того, чтобы выпарсить, к примеру, HTTP-дату, которая лежит где-то в середине byte[], без копирования этого кусочка и трансформации его в отдельный массив char[].
А вот если наши данные представлены в памяти как цепочка или дерево массивов byte[], и дата попала на границу фрагментов, то мы не сможем сконструировать из этих сырых байтов необходимый для Span блок.

С точки зрения перспективы замены штатного класса string на "свои аналоги" это и есть тупик.