Ok, yeah, but it would be only because of the backwards compatibility issue reported here by itself. And it bothers me cause I fear there's this image of me where people can think "Alex will break backwards compatibility to favor max compatibility" and that is not true :) Keeping backwards compatibility is a thing for us and I've said it many times and even put it in cyclone's readme. If there's an issue, if something broke - and that can happen unintentionally - please report. As I explained, this was considered a bug and was an unintentional breakage. I missed the fact that it was documented in prepend's old documentation and that was a mistake. Once you document it, you have to keep it or at least mention you changed it.
And checking purr data's cyclone/prepend, it's even more confusing. It's an abstraction (for some reason) and that just keeps the second inlet with or without arguments, even though its documentation says it's there only if there's no argument.
Well, I'm thinking that the best way to clear up this mess now is to just add and keep the second inlet for all cases and put a note this second inlet in Append and prepend is not compatible to Max. It'd be easier to document it also and it's a less stupid design. By the way, there are other objects in cyclone that do have the same remark of some inconsistencies regarding max compatibility, and even, although rarely, added functionality. I'm openly not a fan of that, but I don't care enough to make a case for it, so I kept it and documented it. I'm just saying this cause, again, I don't want people reinforcing the idea cyclone is now deliberately and mercilessly breaking stuff ;)