This isn't only relevant for Google Drive migrations — it matters for any
migration into Proton Drive, including from a plain local folder.

My case: I wanted to move a 13 GB folder into Proton Drive. That's not much
data, but it consists of 105,023 scanned photos averaging ~130 kB each. The
desktop client managed a few hundred files in the first half hour. At that
rate the upload takes days, because the cost per file (encryption, node
creation, API round-trips) is almost the same whether the file is 14 kB or
14 MB. On my MacBook the sync process sat at 130% CPU for hours with the fan
at full speed and the machine was barely usable. A second folder with 74,536
small source files had exactly the same problem.

The obvious workaround is to zip everything locally and upload a single file.
That works — but then my data is a black box in Drive. I can't browse it,
can't search it, can't preview anything, and to get one file back I have to
download the entire archive. So I'm forced to choose between "usable in
Drive" and "realistically uploadable at all".

Being able to upload one archive and expand it into real files would remove
that trade-off. I understand that E2EE means the server can't do this itself,
so handling it in the client (browser or desktop app) would already be a big
improvement.

And if that's too complex: the root problem is throughput for many small
files. Batching or parallelising those uploads would help just as much — and
would benefit everyone migrating from another service.

Can we expect that soon? It is a simple a function to implement where the client can do on its own in the browser or your designated app.
I would add extract to the title of that feature also

yes please