(Commenting here for both this issue and #647)
Great! This follows what we discussed in December with @steuxyo 😁

I have two main remarks at this point (we can discuss more during the call next week!):

1. If I'm not mistaken, there is an additional aspect where the two implementations above differ: The Dask implementation can manage chunk-reading implicitly from the entire da.Array with defined chunks (so does not need much more than what's written above), while the Multiprocessing one will need to be paired with a custom Rasterio.windows reading (and custom tile definition but this is covered in [POC] Tiling for multiprocessing #649). This "custom reading step" should then be added within the multiprocessing.Pool call above?

2. Also comes the question of the later implementation of these functions within the Raster class. It is doable, but not trivial, because of two reasons: (i) Some raster operations have a "delayed" effect such as crop() (and the recent Raster(roi=)), or Raster(downsample=). We might have to reconcile behaviour for those (for a start we could simply "flag" that a delayed operation is pending and raise an error when trying to combine with delayed multiprocessing, to avoid conflicts). (ii) I might be wrong here, but I think we won't be able to chain several steps, or call a final compute("myfilepath.tif") as easily as with Dask: We'll use this as a 1-step multiprocessing. If that is indeed the case, we'll need to be able to provide a new argument pointing towards an output file for each Raster function producing a large output, like Raster.reproject(filename_delayed_mp=...), to be able to write the output out-of-memory. (this won't concern subsample() or interp())

1. For managing ROI reading, as discussed in the last meeting, developments are in progress.

2.1. Regarding task order management, I hadn't realized this issue. Creating a flag to enable the next steps could be a solution.

2.2. For memory management, we could temporarily store the result in a NumPy array and convert it as needed once all computations are completed.

I'm not an expert, feel free to propose something else

OK for 1 and 2.1.

For 2.2: We can't store the NumPy array in memory all at once, so we'll need to add a function that can write chunks of the output array in a raster file bit by bit with Rasterio.
So "ROI writing" basically, to work in tandem with "ROI reading".

If we make sure that each worker returns the result and that the main process handles the writing, then yes, we will write to the files with Rasterio.