I wrote a small helper whose code and output you can see here: https://octave.discourse.group/t/welcome-octave-packages/2954/17

Right now it only prints the commands but executing them is only an eval() away.

If the user wants only one package, say the econometrics one,  then the line for econometrics says to install econometrics only after installing io, statistics, struct, and optim in that order.

Where should that sort of dependency-scanning functionality be absorbed?

I forgot a bit about my work on pkg.m a while ago (about dependencies and inverse dependencies, etc). At the time I did think about this, and from what I remember it shouldn't be to hard to more or less do the update work safely by implicitly following the dependency tree, w/o actually deriving it. In comment #1 I really over-engineered it.
The private functions installed_packages.m and get_inverse_dependencies.m do the required work. Here's what I was thinking:

Step 1:
'pkg update' could start with updating all packages that have no dependencies; easily derived from the info in the 'installed_pkgs_list' struct created by installed_packages.m. That'll take care of the ultimate "leafs" of the dependency tree.
Most packages have no inverse dependencies so for those the story ends there; they can be marked as 'done'.

Step 2:
Next, get_inverse_dependencies.m could find out which packages directly depend on the ones that are already updated in step 1. Updating those should be a safe action and would take care of a level higher up in the dependency tree. The packages updated in step 1 that hadn't yet been marked as 'done' can now be marked.

Steps 3 - ....
And so on, until all packages have been updated.

Of course there'll be gotchas but that's the fun part :-) For one, think of circular or even entangled dependencies - but do we have those? they'd be a pain when installing anew in the first place. For another, think of required libraries.
Maybe circular deps. can be detected and processed separately for each step 2 and up using the '-nodeps' option, or maybe they can only be updated in the end using '-nodeps', I'm unsure.

It all doesn't look hard to me, but I have no time now to set this up. Some more thinking is required about finding out which packages can be updated safely in the next round and what to do with all the corner cases & gotchas.
But all in all I'd be surprised if this were to lead to more that half a screenful of code. Some while or do...until loop seems ideal for the job.

I don't know about the bigger pkg environment challenge, but I'll take a look at this specific bug. If I can wrap my head around what pkg is doing I'll see if any hacks (in the order specified in my first comment) are workable. Once we have this tackled, I'll start peeking at some of the other pkg project issues, and see if any sit within my current comfort zone. ;)

yes, I realized there has been quite a bit of discussion on modifications to the package handling.  I called this one out here mainly because it seems to be a specific bug with a possible shorter term fix (or hack) that it errors out and fails to continue updating other packages.

what you say sounds ideal. I didn't realize it was sitting in m-code. I may take a peek.

When running 'pkg update' it appears to work through the packages in some particular order (alphabetical order, or install order) When one of the packages has a dependency on a version of a package that has not been updated yet, pkg errors out back to the command line and does not continue checking any other packages for updates.

This can be seen in the windows version of 4.0.0 where the default package set is a bit out of date. Running the build_packages script followed by pkg update gives the following error:

error: the following dependencies were unsatisfied:
> >    optim needs struct >= 1.0.12

And pkg update cannot proceed to other packages until struct is done first. While this is not difficult to do, it may be confusing for a new user.

I would think the simplest solution would be for package to somehow catch the error and step over that package. Then running the update twice would result in everything being fully updated. Perhaps if it needed to step over a package it could tell the user he should probably rerun the update.

Alternatively it would be nice if it would just recognize that it had to step over one of the packages and to try it again at the end. If it failed again and could tell the user.

Really nice would be for it to recognize which package is needed, if it is already installed run that update first, if it's not installed ask the user whether it should be installed, and then after the dependency has been satisfied pick up the update process where it left off.