I think we should be careful that we are solving these problems on the
correct level. Is it the task itself that is taking the time, or is it
the catalogue updates? I suspect in most cases it is the latter, and
the solution then is to make the catalogue itself async by using /
improving QueueCatalog. Doing so does bring some problems though:

This is not necessarily a catalog problem. Talking to third parties for example should almost always be done asynchronously (apis). Furthermore large catalogs take a long time to query as well, not just inserting data. There is no optimization for these, especially third party connections.

That being said I'll admit this doesn't seem like something that affects the majority of people. Those of us that are burned by not having this functionality are really excited, but I'm guessing we are just a vocal minority.
1. User feedback is not immediately apparent, though perhaps this can
be worked around with some creative javascript - after all it's mainly
the user who publishes the large folder that gets an inconsistent
view. Then again, maybe navigation should not be generated from the

This is a good point and I had assumed that this async feedback was not going to go into the core objects, but rather be a developer tool? Managing async interfaces and data is not easy and we can't hope that non-developers will understand wtf is happening. I think this functionality is better suited as a developer tool, an advanced one at that.

All of the sudden I don't think this should be in core plone. If it is integrated, we should start with a *definitive* list of all the scenarios that cause slow response first. This way we can evaluate the actual performance of those things and see if there is an alternative to those first, and after that's been ruled out only then do we look into queuing solutions.

Reverting my +1 to a -1. I 100% agree that we need a solid add on product though.