createCatalogTask catalog_variables: variable-set variables unreachable; string entries silently dropped at build

[IhorKochetkov]

Environment: @servicenow/sdk 4.7.2, Fluent-authored flow using action.core.createCatalogTask with template_catalog_item + catalog_variables, on a Yokohama/Zurich-line instance.

Setup: a CatalogItem() that attaches a shared variable set (standard "Requested For" set used by every item in the org) plus its own inline variables:

export const myItem = CatalogItem({
    $id: Now.ID['my_item'],
    name: 'My Item',
    variableSets: [{ variableSet: '<set_sys_id>', order: 0 }],   // attaches fine
    variables: { short_summary: SingleLineTextVariable({ … }), … },
    // …
})

// in the flow:
wfa.action(action.core.createCatalogTask, { $id: Now.ID['create_task'] }, {
    template_catalog_item: `${myItem}`,
    catalog_variables: [ myItem.variables.short_summary, /* … */ ],
    // …
})

Issue 1 — no way to reference a variable set's variables in catalog_variables

The docs state catalog_variables accepts variable property references ([item.variables.varName]). But CatalogItem.variables.* only exposes the item's inline variables — variables belonging to an attached variable set are unreachable. There is no VariableSet(...).variables.* surface either.

The underlying Flow Designer action supports set variables in its slushbucket (and getCatalogVariables' template input is st_sys_catalog_items_and_variable_sets — "items or var sets"), so this is purely an authoring-surface gap.

Consequence: any catalog item using a shared variable set cannot show those variables on the created sc_task. The only workaround is editing the slushbucket manually in Flow Designer after every install — because each install overwrites the action's values with the compiled list, reverting the manual edit. That makes a fully source-managed flow impossible for this (common) case.

Issue 2 — plain strings in catalog_variables are silently dropped at build

Attempting the obvious workaround — passing the set variable's item_option_new sys_id as a string — produces no build error and no warning; the entry is just absent from the compiled payload. Verified on 4.7.2 by decoding the gzipped values JSON inside the generated sys_hub_flow XML: only the property-referenced variables serialize (as <sys_id>:item_option_new, comma-separated). Both of these are dropped silently:

catalog_variables: [
    '0defe62a…4317',                  // bare sys_id — dropped, no diagnostic
    '0defe62a…4317:item_option_new',  // exact wire format — also dropped
    myItem.variables.short_summary,   // survives
]

If string entries are unsupported by design, the build should fail with a diagnostic — a silently shrinking slushbucket is very hard to notice (it only shows up when a fulfiller reports missing variables on a task).

Asks

1. A way to reference attached variable-set variables in catalog_variables (e.g. expose them on the item, a VariableSet reference surface, or accept <sys_id>:item_option_new strings).
2. A build-time error (or at least a warning) when a catalog_variables entry can't be compiled, instead of silent omission.