Тема действительно очень важная. Но давайте попробуем рассмотреть вот это предложение более детально, хотя бы применительно к приложенному случаю. Слово "Шайба" опустим и перейдем к сравнению "2.5.65Г.013" и "2.65Г.013". Сравнение в T-Flex посимвольное, т.е. различия в строках начинаются с 3-го символа, а это - "5" и "6". Соответсвенно, запись с "6" ставится ниже записи с "5". T-Flex работает правильно.
Проблема в том, что T-Flex сравнивает строки, содержащие сумму значений всех параметров, а не последовательность значений параметров ("Шайба", d0, $T, $Matsp, $Pocr_nom, "ГОСТ%%S6402%%-70"). Чтобы T-Flex попарно сравнивал значения параметров нужно, чтоб из переменной - в данном случае $sp, особым образом считывались все другие переменные и константы, входящие в выражение переменной $sp. Вероятно, прежде чем считывать их "особым образом" нужно сначала внести их в выражение "особым образом", потому что существует другой случай вместо записи:

Шайба 0.3-2-6-Ц ОСТ 1 34505-80
Шайба 0.3-3-7-Ц ОСТ 1 34505-80

использовать запись:

Шайба ОСТ 1 34505-80
0.3-2-6-Ц
0.3-3-7-Ц

Для такого случая система должна распознать, 3 составляющие наименования: название изделия, его параметры и обозначение нормативного документа. Я конечно понимаю, что кому-то "не надо сигарет, достаточно махорки" (если мне память не изменяет), но приведенный мною случай я взял не с потолка, а из ЕСКД. По этой логике - у нас должно быть уже 3 группы параметров для сравнения. Если следовать "букве закона" (ЕСКД) и этой логике, то для правильной сортировки нужно чтобы пользователь (разработчик библиотечного элемента) правильным образом вбил все необходимые параметры в редакторе переменых. Это может оказаться накладным, т.е. "шкурка" перестанет "стоить выделки".
Самое обидное, что даже если выполнить все то, что я тут понаписал, то можно не увидеть ожидаемого результата.

P.S. Недавно я потратил около месяца непрерывной работы над проектом программной сортировки разделов спецификации (и не только). Сейчас работа приостановлена на неопределенный срок, главным образом, из-за ошибок в спецификации и недостаточного функционала. Однако, я отдаю себе отчет в том, что работа со строками не может привести к желаемому результату и покрыть на 100% все возможные случаи. Для нормальной автоматической сортировки в разделе "Стандартные изделия" необходимо другое решение. Думаю, что это станет доступно лишь в не близком будущем...

При выполнении операции "сглаживание ребер" для единичных ребер или при отключении "Общие параметры" предусмотреть указание длины участка сглаживания (можно через положения точек начала и конца отрезка в абсолютных величинах и относительных величинах) с предложением вариантов обработки окончаний.
Пример (*.jpg):

В эскизном черчении в функции построения правильных многоугольников предусмотреть возможность задания числа сторон через переменную. А то как-то недобно получается.

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

Для операции "Оптимизация":
1. добавить возможность описания значений с использованием переменных;
2. добавить возможность одновременного запуска процесса оптимизации по нескольким направлениям с учетом заданной последовательности;
3. предусмотреть "выделение" целевых и оптимизируемых переменных в "Редакторе переменных" с указанием взаимосвязей и критериев;
4. предусмотреть возможность запуска процесса оптимизации из "Редактора переменных" для обозначенных по п.3 переменных с возможностью;
5. И вообще, почему бы не внедрить функционал операции "Оптимизация" в "Редактор переменных" с соответствующей унификацией?

1. Реализовать механизм создания профиля по последовательности 3D путей (как замкнутой так и разомкнутой – например для операции «Гибка»);
2. Предусмотреть возможность создания поверхностного тела путем заполнения контура ограниченного профилем или 3D путями. В качестве профиля должны быть использованы как плоские так и пространственные (например: профиль на цилиндрической рабочей поверхности) структуры. Для пространственных структур предусмотреть на выбор несколько механизмов заполнения: параллельное перемещение прямой линии касательной к двум точкам линии профиля в заданном направлении; вращательным движением прямой линии, касательной к линии контура, относительно фиксированной точки; перемещение линии касательной контуру в двух точках, положение которых определяется параметрически и пр. (что то например по типу "Операции|Грани|Заполнение области"
но для контура из профиля или набора путей)
3. Предусмотреть создание профиля (или 3D пути) по линии пересечения поверхностей. (хотя бы расширить функционал операции "Построения|3D путь/Создать 3D путь на основе сечения тела плоскостью").

Необходимые результаты по данным пунктам можно получить и на реализованном сейчас функционале TF но через определенный "танец с бубном". Хотелось бы более конкретных решений.

При повторной (бесконечной) вставке предыдущего фрагмента ввести возможность "запоминания" исходной КС, назначаемой из меню вставки фрагмента.

А не проще ли ввести возможность задания сопряжений к элементам построений, которые могут приводит к трансформации оных.
Например при задании параллельности профиля к криволинейной поверхности (плоскости) на заданном расстоянии - плоскость контура также становится криволинейной.
Для сферической или цилиндрической плоскости - этот контур будет уже концентричным (соосным) в пространстве и т.д. и т.п.
А Преобразование оставить только для разборки.

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

Часто при редактировании геометрии возникают ошибки, связанные с "потерей" или изменением вида родительских элементов. Причем TF на эти ошибки как правило указывает.
Ряд систем (например Pro/E) в данном случае предлагает варианты устранения ошибок, причем значительную часть работы при этом проделывает программа в автоматическом режиме. Почему бы не реализовать что то подобное в TF.
Например: при редактировании геометрии часть ребер из цепочки, по которым было выполнено скругление, исчезло (они помечены крестиком при редактировании операции), почему бы не предложить их автоматическое удаление из списка или, если необходимо, дать возможность пользователю их последовательно переназначить. Таких примеров можно провести много.