The error could be more clear but in practice a Cashtab user is never expected to see this error. The component manages user input and just assigns 2 if the user is creating a token with a mint baton:

const configObj = {
            name,
            ticker,
            documentUrl: url === '' ? tokenConfig.newTokenDefaultUrl : url,
            decimals,
            initialQty,
            documentHash: '',
            mintBatonVout: createWithMintBatonAtIndexTwo ? 2 : null,
        };

This function can be called with mintBatonVout = 2 -- this will create a variable supply token.

per nft1 (and slp1) spec, we could have the mint baton anywhere (except 0 or 1) ...so, it we could have a genesis tx that, say, op-return at index 0, sends the created tokens to output 1, sends millions of xec to dozens of other addresses, then creates a mint baton at output 79, then sends other amounts of xec to other addresses at outputs 80 thorugh 137.

Cashtab imposes some restrictions on top of the slp1 spec to simplifiy the scope of txs available to a user. For all slp1 tokens, we allow the user to create a mint baton -- but only in a simple genesis tx where the only outputs are script, genesis qty, mint baton, and ecash change if applicable.

We are imposing another one of these cashtab spec constraints in this diff by only accepting decimals as 0 for nft1 parent tokens. This is recommended by slp spec but not required. Decimals is not something the user has any influence over, so this is hardcoded by a constant.

Available option to replace mintBatonVout with a constant like createWithMintBaton, then hardcode the 2. This is arguably "better," but imo the API used here is not really a problem and is more extensible if we decide to support "not-two" values later on. The approach here also mimics what was done for non-NFT genesis txs.