the view consistency/snapshot probably also belongs here?

In that context, would be interesting to know how fabric currently does it: do they serialize update and endorsement or do they maintain different ledger states/views concurrently? the former is of course the easiest to implement (though requires an explicit notification by ecc that a tx is finished) but also means that a slow tx can hold of others (not that this is probably immediately the biggest concern for us :-))

(this in turn might ask for adding eventually the endorsement equivalent of the "Fabric high-level validation" section above?)

monotonically increasing version numbers for us will be a bit a challenge with it being MRENCLAVE ... ;-) [different story of course for ercc, though not sure whether for us the version really matters for ercc (compared to sequence numbers) as we look only at meta data changes and on that level version doesn't really have any effect? It is only relevant during the actual execution of the endorsement (which we delegate to normal peers for ercc)?

not sure what exactly you mean here ..

somewhere we definitely have to be more explicit where we abort and, in particular, where we (safely can) ignore. My feeling is that by default we should abort and ignore only for explicit cases where we know it's safe to ignore ..

Related to above i guess is also to make tlcc maintain all state, not only meta-data (thereby also removing any issue of synchronicity between peer and tlcc (at least as long as we do not go to cc2cc between fpc and non-fpc chaincode ...)

by data you mean actual ledger data and meta-data?
also, adding persistance to tlcc is more mid-term rather than short-term? Or do you see a low-hanging fruit where we get that for (almost) "free"? (If we restrict that state must fit into EPC and we write and read a snapshot in one go , we actually would not really have to do merkle tree and alike and a simple HMAC (based on some seal-key) protected snapshot should be enough?)

All these requirements really come from the fact that TLCC is implemented as a separate entity. In particular the implementation does not use the original peer's ledger Go code and, yet, it has to match its functionality.
A couple of lines at the very beginning could clarify this.

Is the approach to modify Fabric in order to reduce the validation steps?
I think here you mean: design/implement a reduced validation procedure in TLCC -- compared to Fabric's legacy one.

Definitely desirable, but my doubt is whether this is possible, given that ERCC and ECC are normal chaincodes, for which we run the normal validation procedure. However, this could open the possibility to implement specific validation plugins for both of them, avoiding the legacy validation. By doing this, we control the entire validation logic; we can implement a simple one and mirror the implementation in TLCC.

In practice I would expect an FPC release, say 2.2, to support Fabric 2.2. Then, when Fabric 2.3 comes out, a new FPC should follow to support it.

As I mentioned, implementing the snapshot approach might add a non-trivial complexity.
However, a consistent view might still be achieve by "playing" with the block height: either the chaincode or tlcc abort if they start a session with block height x and terminate that with block height y (meaning that there have been updates).