I think this is probably the best option. Figuring out how to handle decimal changes is a big can of worms.

Yes, that seems to be the consensus.

For context, L1 deposits do not check decimals at all, and it's perfectly the same to do the same here (remove the check altogether). In that case, the market should adjust the pricing for each representation.
So, both approaches are safe:

• enforce the same decimals
• don't enforce and let the market price the assets
  I think it's mostly a UX decision.

How will this list be populated?

It would be relatively straightforward to do this trustlessly but would require that we have an external function that can be called to populate the mapping. I would prefer that over a trusted solution.

@smartcontracts the idea was to do it in a trusted manner, here's a relevant comment from @tynes: ethereum-optimism/design-docs#46 (comment), proto had suggested a slightly different approach using an onion-hash, which is the R&D discord

We can assume that the mapping will be populated correctly as part of this spec, we can work on a design doc for how to populate the mapping separately

Sanity check: do we assume that the remote token address is always an L1 address? Is there any case where the remote token address may not be an L1 address?

For the scope of this spec, we can assume the remote token is an L1 address.
We had an internal discussion on whether to name it l1Address or something similar for this spec. Still, we went for the remote naming because we think a similar logic will eventually be used for L2 native tokens, where the remote address will not correspond to L1 but to the native L2.

This comment is going to go stale, meaning that at some point it will no longer be the latest implementation

I recommend just removing this paragraph and adding a paragraph that says that the mapping may also be filled with addresses computed from alternative mechanisms for some chains

I think that we should add the spec for how the salt is computed. This is useful so that we can reason about invariants around how the deployments mapping is populated.

Right now it is:

bytes32 salt = keccak256(abi.encode(_remoteToken, _name, _symbol, _decimals));

Since this isn't done with create3, a change in the solidity compiler version will result in different addresses. If it is easy to migrate to a create3 deployer, that would be preferred, but certainly not required. For the new factory we would definitely want to use create3

I changed the paragraph to be as open as possible, only discouraging the use of CREATE, discussing the issue with CREATE2 and suggesting CREATE3 eventually.

Would you like us to work on a dedicated spec for the salt of the OptimismMintableERC20Factory then?

What is the additional work in your mind besides what i linked above?

Nevermind, lol. It would not be worth.
I modified the paragraph in the latest commit. Let me know what do you think of it.