from what you say, I understand that in order to force a certain directin of DSP flow (either directly, or as in the execution order example), I *have* to use patch cords in one way or the other. OK.
this is sadly true ...
I admit that I am rather clueless with respect to core programming, but if that is the information that is needed by pd to sort things right, then implementing a "substitute patch cords by send~/receive~"-feature wouldn't seem especially non-trivial to me (although it is certainly more work than I imagine at the moment).
not as easy as it seems ... with s~/r~, you can easily have loops in the dsp graph ... it only adds a block delay ... i once had a look at it ... isn't that trivial as it seems... the biggest problem is ... the graphical representation is _exactly_ the same as the internal representation ... this makes it pretty straight forward to use it, but has some severe limitations ... in theory, it should be possible to optimize both dsp and message graph ... but i see very little hope to implement this in pd ...
cheers ... tim