Here's my take on each of these, leaving out async as that'd be more dependent on where we were:
Secrets Manager
Many environments Django is deployed in use a separate secrets manager to store and provide secrets per environment - either as environment variables, files, or via a direct HTTP API. The project would be to design and add an abstraction interface over secrets managers that allows users to easily map to an external secret in a settings file. There's also room for giving Django a better, built-in per-environments settings option too, pulling from popular third-party patterns.
Django Service Hooks
Django has a lot tied to the HTTP lifecycle, and if you run it outside of this, you miss out on some key things - like database connections being closed properly, or logging, or some middleware. The project would be to design and implement a separate way of calling Django from a service framework - even if that framework was itself HTTP based (basically, don't rely on Django having to run through WSGI/ASGI). Initial idea is to provide a context manager that replaces the wrapping of a request, but the project would have to include requirements-gathering and interviewing people who use Django to power microservices to work out what they want.
Evented Datastores
Evented, or event-sourcing, database schemas are growing in popularity - essentially, a way to implement an append-only pattern on top of a relational database, where every single event that has happened is stored, but you can still efficiently retrieve the current state of an item. Given the way the pattern works, this would be possible to implement on top of Django models - likely as a whole new Model subclass - and implement with a matching QuerySet/Model API. It would require someone very skilled in database design, and it's also arguable if it should be in Django itself, or comprise of developing a third-party app alongside adding hooks/fixes to the Django ORM where needed to make it work well.
GraphQL
Basically, work on an "official" graphql-to-ORM mapper for Django, probably re-using a considerable amount of third-party work. This one could really vary in its application, based on how much other "API-ish" work the project includes (given that Django REST Framework is still separate, we should follow that rough pattern).
Plus, some bonus ones that aren't Django code itself:
Django Case Studies
Our long-talked-about website which brings together case studies and white papers about why people choose Django, aimed at companies working out what they want to choose. This is likely only some coding and a lot of writing/legwork, so may not be a good fit for GSOC, but should be on any future plan we have.
Django Benchmarking
Django has had a benchmarking suite for a while, but we've generally got more slack at tracking the effects each commit and release has. We should institute a set of top-level benchmarks aimed at various areas (the current set in djangobench are weak in, say, the HTTP-serving-speed area) and then run them against pull requests and each release, so we can make sure Django doesn't get slower while nobody is looking.
I'm sure there's a lot more, but these are top of mind at the moment!
Andrew