Можно сделать глобальный метод Set(A, B = Undef, C=Undef)  и т.п. который будет готовить массив из переменных, и глобальный метод Unset("Key1", Key2") и т.д. который развернет в структуру с ключами

получится

Function Foo()
Return Set(0, "Val1");
EndFunction

Procedure Bar()

Res = Unset(Foo(), "Value1", "Value2");
Res.Value1;//0
Res.Value2;//Val1

EndProcedure

а что сразу структуру с ключами не возвращать тогда?

Ну сет используют обычно тогда когда не хотят завязываться на имена свойств а только на порядок 2-3 переменных

Разворачивания сета сложно сделать, либо надо Unset делать чтоб он делал структуру либо передавать ему указали на переменные чтоб он в них записывал.

и то и то кажется костылем

Спасибо

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

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

ну так я и горю о кортеже через set

по другому его как то можно сделать?

Можешь назвать это как глобальную функцию Tuple) но не имея метода рапаковки кортежа как в питоне или js все равно надо что-то будет городить

вот так в питоне, а в js вот так деструкция кортежа идет

tuple = #['a', 'b']
[a] = tuple

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

с бодрым. решил начать борьбу с врезками, хочу поддержки единомышленников, если конечно в правильном направлении двигаюсь. суть в следующем. дорабатываем типовые конфигурации. расширения использовать нельзя. иногда доработка заключается буквально в нескольких строках - поменять какую-нибудь аналитику. в этом случае делается "врезка" в типовой функционал, все более-менее красиво оформляется и комментируется. затем делается еще одна врезка и еще одна и так до тех пор пока глаза не зарябят :) хочу для подобных случаев ввести правило постобработки - условно выполняется типовой код, а перед возвратом данных управление передается в нетиповой модуль где все врезки собраны и будут продолжать собираться в одном месте. цель - минимизация трудозатрат при обновлении на новый типовой релиз, разделение типового и нетипового кода, "гарантия" если так можно выразиться применения доработок и может быть что-нибудь еще, о чем я забыл :) такой подход имеет право на существование?

В условии когда нельзя использовать расширения - это правильный подход.
Он же описан в стандарте https://its.1c.ru/db/v8std#content:554:hdoc
В котором ты делая дороботку типовой берешь ее за библиотеку, добавляя врезку добавляешь переопределение, реализуя врезку - реализуешь модуль специфики.

Еще более правильным подходом будет просить на партнерском форуме типовой добавить то переопределение, которое тебе потребовалось на внедрении, чтобы оно попало в код типовой конфигурации.

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

Пока чёрный ящик написан не через пень-колоду - можно :)