There is a lot of issue with the current automatic updater and the current update process, so here are our proposal:

Adds new update button in the ACP

First step: upload a package and check it

Download the appropriate update package from phpbb.com

Download a signature from the same website

Calculate the package checksum

Decode the expected package checksum from the signature using a public key already available (the public key will be present in the install package and could be updated by any update package. If the key does not work, we will ask the user to download it from phpbb.com but it shouldn't happen a lot of time, the public key shouldn't change unless phpbb.com has been compromised)

Second step check requirements

Check PHP version and others PHP requirements (extensions or anything else) using the current files (this way, we can display a nice message and abort even if PHP is not compatible with the new version)

Check other requirements (write right or DB version per example)

Calculate and compare the checksum of all files in the update package. Abort with an error message if one of them differ

Third step: update files (replaces old files by the new ones)

Fourth step: pre db updates (config.php fixes per example)

Fifth step: db-update

Sixth step: cleanup

Later we could imagine seventh step: updates extensions (but it needs another work before that)

Note: phpbb.com refer to phpbb.com or any other configured source (for IST per example)
Note: A such automatic updater needs 2 things:

As a website administrator who also uses WordPress, I'd strongly recommend reviewing their model and implementation, including giving the admin the ability to Configuring Automatic Background Updates « WordPress Codex. I always turn the automatic background updates off because I want control of the timing and the ability to test before deploying.

That's the point of this though and I'm in favor of dropping support for the diff'ing of files, i.e. auto update package. It will then be the responsibility of the admin to reapply those changes on their own during updating. Since WordPress is being used as an example it doesn't preserve code changes either and they warn about this. The auto updater is a bit buggy and is tedious to prepare so I see very little reason to keep it.

That's the point of this though and I'm in favor of dropping support for the diff'ing of files, i.e. auto update package. It will then be the responsibility of the admin to reapply those changes on their own during updating. Since WordPress is being used as an example it doesn't preserve code changes either and they warn about this. The auto updater is a bit buggy and is tedious to prepare so I see very little reason to keep it.

I would also go down that route

===============================================================

With the "One click update" which is basically an automated changed files process the one thing that has to be "replaced" currently is the the vendor folder. This is quite a large, and growing, folder and if the whole folder is going to be part of the update then, because of its size, this might become a problem.

Another point to consider is that if this is not going to be included until 3.3 then there will be the problem of all updates until then and also the the upgrade from 3.2 to 3.3. Whilst I know that features are not normally added to minor updates I would suggest that this feature is considered for 3.2 as soon as it is ready rather than waiting for 3.3

DavidRemember: You only know what you know -
and you do not know what you do not know!

@Nicofuma: I'm curious about how this proposal will work if the vendor folder has to be updated. Currently the vendor folder has to be deleted and a new one uploaded. If the one-click update has to depend on things like Symfony for instance then it won't work.