Thanks for clarifying @Pete. Presumably the ‘ckERC20 Ledger Suite Orchestrator’ canister therefore shouldn’t need upgrading to a new binary (just to facilitate a function call to add the new ckERC20 token to the canister configuration and create the new ledger suit). But unless I’m mistaken it looks like the intended pathway for triggering this is a ‘System Canister Management’ (SCM) proposal, executing the NnsCanisterUpgrade function (is that correct?).
In an ideal world, wouldn’t it be worth avoiding desensitising the community to SCM proposals proposed by unrecognised neurons / non-Dfinity devs (given the potential for such proposals to modify critical system components). It feels like this sort of thing should have a dedicated proposal type with limited scope in terms of the changes it can apply.
Please let me know if I have the wrong end of stick.