to make the migration simple, I created two helper functions:

uint8_t getSTB() {
    return (uint8_t) SCPI_RegGet(&scpi_context, SCPI_REG_STB);
}

void setSTB(uint8_t stb) {
    SCPI_RegSet(&scpi_context, SCPI_REG_STB, (scpi_reg_val_t) stb); 
}

bool tud_usbtmc_msg_trigger_cb(usbtmc_msg_generic_t* msg) {
  (void)msg;
  // Let trigger set the SRQ
  uint8_t status = getSTB();
  status |= IEEE4882_STB_SRQ;
  setSTB(status);
  return true;
}

Now ready for the step that I think is needed, to make the SQR / trigger mechanism work: merge the status byte of the USBTMC code, and the one from the SCPI-LIB

I kept the one in the tmcusb code from the TinyUSB example. I think that's a mistake, and should have ported the STB of that example over to the STB of the SCPI-LIB.

To make the work structured, I abuse the compiler: I commented out the status variable in the STB code part. To make the compilation fail. I marked the line with a TODO comment
Then compiled the code, and also marked each of the compile error lines with a TODO command.

VSCode (like many IDEs) has a TODO module that lists all the lines with a TODO comment. I can now navigate to these lines easily, and fix them one by one until the compilation succeeds again.

This functionality is now available in the development branch: https://github.com/jancumps/pico_scpi_usbtmc_labtool/tree/develop-set-4

making the usbtmc event service request channel work is still a far dream, but I have progress on dealing with the registers.
All required SCPI commands are now implemented:

    // instrument specific registers commands
    {.pattern = "STATus:OPERation:DIGItal:INPut:EVENt?", .callback = SCPI_StatusOperationDigitalInputEventQ,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:CONDition?", .callback = SCPI_StatusOperationDigitalInputConditionQ,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:ENABle", .callback = SCPI_StatusOperationDigitalInputEnable,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:ENABle?", .callback = SCPI_StatusOperationDigitalInputEnableQ,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:PTRansition", .callback = SCPI_StatusOperationDigitalInputPTransition,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:PTRansition?", .callback = SCPI_StatusOperationDigitalInputPTransitionQ,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:NTRansition", .callback = SCPI_StatusOperationDigitalInputNTransition,},
    {.pattern = "STATus:OPERation:DIGItal:INPut:NTRansition?", .callback = SCPI_StatusOperationDigitalInputNTransitionQ,},

Test with NI Visa Interactive

output:

# button not pressed: input 27 (bit 3) high
1: Write Operation (STATus:OPERation:DIGItal:INPut:CONDition?\n)
2: Read Operation
4\r\n

# button pressed: input 27 (bit 3) low
3: Write Operation (STATus:OPERation:DIGItal:INPut:CONDition?\n)
4: Read Operation
0\r\n

for git lovers: I'm working on this experimental feature outside of the "scheduled" new features. An experiment has a different pace than "normal" new functionality.
I created a dedicated branch for the experiment, based on the (at that time) current release. You can see that as the green track on the graph below.

Meanwhile we were working on the next "normal" release, adding several incremental features. You can see that dev branch (develop-set-3) in the blue trail.
When that develop branch was cut as a new release (version 3.0), and I merged the dev branch with the main one, my experimental branch was outdated.
You can see the black arrow on 18th (today), where I synchronised the experimental branch with the main branch, to eat the changes done for this release.
Now my experimental branch is up-to-date with the release 3.0. While safeguarding my experimental changes.