Why is there a custom SelfContained extrinsic variant if there are SignedExtensions?

[MOZGIII]

SignedExtensions can do everything that SelfContainedCall can do, but it seems like landing that would be way more compact. Why does SelfContainedCall exist?

Some context: the original rationale is provided at the #482.

It states:

Why do we have to define our own CheckedExtrinsic given that Ethereum transaction senders already have mappings to AccountId?

We must not use any existing SignedExtensions. They added things that should have been signed by the signature, but we don't have the means for additional signatures. In addition, if included, they will lead to double charge of transaction fees and other unwanted side effects.

The SignedExtensions invocation logic is handled in CheckedExtrinsic.

My point is, you can handle what frontier needs perfectly fine with SignedExtensions - just treat the call as unsigned with a custom SignedExtension. In this sense, the signature, which is inside of the Call::transact{ transaction } can be validated via SignedExtension just at all the same places as it currently is with the custom UnheckedExtrinsic/CheckedExtrinsic. It integrates nicely with RawOrigin too.

I don't quite follow the argument of double charge - how would that happen, and why would it not be happening here? We do have to spend the cost of tx validation more than once (for tx pool, for block, etc - just the same way as with the rest of the substrate extrinsics), but the fee is only charged once.

CC: @sorpaas, @xlc

UPD: further investigation shows that #495 exists, which contains a huge discussion.

#495 (comment) states that there's access to the necessary life-cycles, which doesn't seem like a valid statement to me. I'd like to know more, because to me it seems like a simple execution with substrate rules would work here.