Thanks for the quick reply!
After posting my request yesterday, I couldnt stop thinking about the whole cargo loading/unloading issue. It keeps me the half night from sleep and things got worse, the longer I thought about..
Probably, my conclusions are of interest to you.
1. A change of this scale in the ecosystem would change the whole gameplay completely. So, is a "patchpack" the right place to alter the game completely or it's maybe wiser to do it in the openttd main trunk?
2. The patch, I posted yesterday does not the whole thing. It only makes possible to load/unload a specific cargo. It should be possible to load/unload a specific AMOUNT of cargo.
3. Concerning the GUI and the whole organization of the function it might be a good idea to introduce "suborders" where either the currently availible load/unload options are part of (the suborder list) or the suborder-list is referenced as a load/unload order. I hope you understand what i mean, sry for my english...
4. Refitting cargotypes could also be done as suborder, so manual refitting at a station is not limited to one cargo.
As of writing this, I will be not upset when you tell me that a change in such scale is too much work and if I want those features I may do them by myself..
I wouldn't stress about this sort of thing if I were you. There's no rush and it's not worth losing sleep over.
To answer your points:
1. I don't see how it is such a significant change? The gameplay mechanics are not fundamentally different. I would doubt that trunk would be interested but you're free to approach the devs if you like.
2. That seems a bit too much like scope creep to me. How often is that sort of thing really useful, when how much to unload is generally handled by cargodist anyway?
3. That sounds a bit overkill to actually implement. I was thinking more along the lines of adding lines like: "Full/load/transfer/etc. all cargo of type(s): LIST" however many times is necessary.
4. This also seems a bit like scope creep to me.
The main reason why I thought about this previously was for distribution of cargoes like FIRS Engineering Supplies (which often move in the opposite direction to bulk cargoes). In particular doing transfer orders when on the same train as the bulk cargo, and preventing the cargodist graph from gaining unintentional edges in the "wrong" direction, which can also cause problems.