I gave some further thought to the questions around extensibility of custom serializers, and I think the key problem may be that `JSONMessagesSerializer` is itself a bad idea, and a bad example for the community.

The right reason to create a custom session serializer is because you have a certain generic type of object (e.g. datetime) that you want to be able to store in the session from a variety of different places in your code, and the serialization logic should be centralized in one place.

But for highly purpose-specific serialization like this, where there is just one fixed session key and one code location where the data is being read from / written to the session, the better answer I think is to simply perform the serialization at that higher level, and store serialized data to the session.

So I don't think `JSONMessagesSerializer` should exist at all (which solves the ugly issue of putting it in the default project template `settings.py`). Instead the messages session backend should do the serialization itself and store only safe data in the session.

I also think this means there isn't really a need for a more complex hook-based API like @apollo13 had suggested. Custom session serializers should be relatively generic (in fact, if Django's default one gained the ability to handle datetimes, dates, and a few other common data types, I doubt most users would ever need a custom one at all). Third-party apps requiring their own custom session serializer should pretty much never happen; those apps should instead just provide API wrapping the session access (like `contrib.messages` does) and handle the serialization at that level instead.