Not sure I fully understand. The critical piece of code is always executed on a fully deserialized object. So the approach should work (or I apologize for not having understood the subject matter).
I did not question your approach, I wanted to point out that in the attack vector, i.e. InvokerTransformer#transform will already be called during de-serialization (of another object).
However, awareness is required on how people have to deal with this finding. The lib is very wide-spread. Thus a minimum behavior change in the software stack is preferred.
We are trying to do this, but the rationale is as follows: if an application uses the unsafe classes in a legit way, i.e. will de-serialize them from a trusted source, the application will most likely also use these objects in a way or another. It means that the application will fail in any way, but it will be easier to spot/fix if it happens already during the de-serialization, but please correct me if you have a use-case where your approach would be more suitable.
For newer versions (major/minor) I would agree to your fail-fast approach. Here I would also suggest to remove the complete Serialization feature.
This is indeed the plan, for the 4.1 release we will hopefully remove the Serializable interface from the unsafe classes.