I proposed EIP-1344 for Istanbul because I think it’s the most straightforward and flexible proposal for managing chain ID-based domain separation in the application layer. I don’t believe EIP-1965 has to be Accepted to be proposed for Istanbul, so that should not be an issue in proposing it. It does however have several unresolved technical issues concerning how it might be implemented which are being worked through as we speak.
There are many potential use cases for chain ID in the application layer, many of which may yet to be discovered. Some of them require consideration of a change to the value of chain ID in a contentious fork scenario, which is easily implemented in application code per the requirements the developer has for those scenarios (if such a feature is required). EIP-1344 does not wish to be prescriptive of how these scenarios are resolved, instead providing the rationale that developers should consider this scenario when implementing it in their application. Being too prescriptive could potentially be burdensome to the application developer in some circumstances.
That being said, there are scenarios where having access to a list of prior chain IDs would be helpful, namely the use of “counterfactual” settlement contracts where transaction history needs to be processed (in scenarios where the results are not simply aggregated in a final message).
I will also state for the record that EIP-1959 was proposed alongside EIP-1344, and may be complementary to it. An oracle contract could be developed to satisfy the intention of EIP-1959 or EIP-1965 if EIP-1344 were made available, with only a marginal increase in complexity of the mechanism required for it to work correctly (the block heights might end up a few off of the true height where the contentious split happened).
There are many options here, and I believe EIP-1344 to be the simplest and most straightforward since the information is already accessible in the VM execution context due to EIP-155, as well as the fact that we haven’t seen a contentious split with EIP-155 implemented at the present time (and that we have no actual process in place for changing it in light of a contentious fork).
Edit: I added a link to an example implementation of such a trustless chain ID oracle contract leveraging EIP-1344 to the forum for that proposal here: