Currently, a type string of DateTimeImmutable will be parsed as DateTime. This, for example, leads to any entity properties annotated as @var DateTimeImmutable to be hydrated into a DateTime class instead.

Note that this is a hotfix at most, because the real issue is, that the regex does not check for a type ending character, like whitespace, line end or another non-word character. Therefore, it eagerly parses DateTimeImmutable by matching the DateTime prefix and taking that as the parsed type, which is wrong.

The format for converting from JSON encoded DateTime was wrong. The format doesn’t use the \T separator, but a whitespace and as it seems, v is not a valid format specifier for DateTime::createFromFormat while it is for date().

In multiple permutations, we tried to fix problems with cache identifier
uniqueness in cache backends that are shared like apcu or memcache.
In earlier days it included the PHP_SAPI and then in more recent times
the context and root path. With the refactoring of caches, these two
became the hardcoded applicationIdentifier which can be used by
any backend to add more specificity to cache identifiers.

It turns out that the root path doesn’t work well for some environments
and can result in bugs when used with eg. the PdoBackend and a
deployment that changes the root path (typical Surf or Deployer).

The only backward compatible way to fix this was to make the
applicationIdentifier configurable with a default that matches the
previously hardcoded values. That way nothing changes in existing
installations but if the bug appears it can be easily fixed.