Yes, if Flink does not recognize your registered state type, it will by default use Kryo for the serialization.
And generally speaking, Kryo does not have good support for evolvable schemas compared to other serialization frameworks such as Avro or Protobuf.
The reason why Flink defaults to Kryo for unrecognizable types has some historical reasons due to the original use of Flink's type serialization stack being used on the batch side, but IMO the short answer is that it would make sense to have a different default serializer (perhaps Avro) for snapshotting state in streaming programs.
However, I believe this would be better suited as a separate discussion thread.
The good news is that with Flink 1.7, state schema evolution is fully supported out of the box for Avro types, such as GenericRecord or code generated SpecificRecords.
If you want to have evolvable schema for your state types, then it is recommended to use Avro as state types.
Support for evolving schema of other data types such as POJOs and Scala case classes is also on the radar for future releases.
Does this help answer your question?
By the way, the slides your are looking at I would consider quite outdated for the topic, since Flink 1.7 was released with much smoother support for state schema evolution.
An updated version of the slides is not yet publicly available, but if you want I can send you one privately.
Otherwise, the Flink docs for 1.7 would also be equally helpful.