I think that Miller has the absolute right to not accept patches, either because they touch parts of Pd that should be left alone or because they are just too big. Incorporating patches is a task that takes a lot of care, I had to realize that when I included the alsa-midi patch into the Debian package.
sure, it's miller's right to reject patches ... like it's my right to fork from pure data to release and maintain my flavor of pd ;-) none of these solutions it optimal, though ...
Changing the scheduler is not a minimal change. I also think that the SSE code can be maintained apart from the main pd. For PDa I have just
well, i never said that the changes are minimal ... but changing the scheduler was necessary to achieve better latencies ... the sse code can't easily be separated from the pd kernel, since functions are used for both dsp objects and the dsp tree ... beside that, no one has to use the simd code ... the inclusion of the simd code is a compile time option ...
Anyhow, what I want to say is that structuring the changes might help the transition. And even if your additions don't go into the main Pd distribution, this scheme also helps to port them to a new release of Miller, because your changes in PD itself are just some "hooks" to your code. (this was my main concern when chosing this structure).
you can probably use hooks for a few tasks, but it's getting difficult, if you are adding features, that you want to use / export for external developers (e.g. tooltips or idle callbacks)
I admit that this probably won't work for the soundfiler and array locks, but it would mean that this patch would be a few lines of code and maybe gets accepted by miller.
one example ... a few days ago i improved the data structures for the clock callbacks (from a singly linked list to nested lists, still O(n), but faster than the old implementation) ... since i can't run the clock callbacks in the dsp callback (threading issue), i introduced a run_clock_callback function that's run in both the traditional and my scheduler for callback-based dsp ticks ... now i can write a patch to port the improvement back to stable, but this would conflict with another patch i would write to submit my scheduler changes ... during this time, i could probably find out, how to implement the tooltips for outlets ...
cheers ... tim