We did option #1. No problem.
Troggle has two "users", each with a password. They are managed by entirely separate systems:
The first of these is managed by the 'django-registration' plug-in package which is in its second generation (it was rewritten entirely in 2015).
The second, the django administration user, is part of the core django Users/Groups system'django.contrib.auth'.
The original design of Troggle envisaged that expo cavers would have their own individual logins and manage their own accounts, which is what 'django-registration' is designed for. It easily handles the hundreds of accounts which would be necessary. (See " Troggle: a revised system for cave data management")
The django administrator account is built-in by default and created when the database is initiated.
The 'django-registration' plug-in package is responsible for nearly half the grief we have upgrading Troggle every time Django releases a new version (every 8 months or so). Even if we delay upgrading to the next Long Term Support (LTS) release that is still every 3 years and we have to do all the intermediate upgrades anyway.
This is a lot of effort, for just one user id. Especially when we have another, obligatory, user registration system already.
We edit troggle to create two ids when resetting: "expoadmin" (the django administrator) and "expo" (to have access to Austrian cave surveys and edit pages). These will both be created by the 'django.contrib.auth' system. Django gives us fine-grained access control settings for admin users so we can ensure that "expo" has the minimum necessary but has file upload permissions
We remove the 'django-registration' system entirely which reduces the attack surface of troggle - and the enforced deprecation/upgrade process certainly feels like an attack.
We change the name of the django administrator login to "expoadmin" as in proposal #1.
We write out own code to manage the "expo" user's capabilities and login GET/POST form (which would still have to use Django's form POST mechanisms because of session handling, CRSF security, cookies etc. etc.).
It might appear that proposal #2 would be on the road to eventually leaving Django, but because of the security issues it wouldn't really. This would all need to be rewritten again when we leave Django. So I think Proposal #1 will require less wasted work.