That would be a very welcome feature.

One bonus feature would be the ability to set a "disabledGroup" or similar attribute that would disable every button in that group if one
of them is processing a request.

And if all this would be applicable to commandLinks also, all the better.

And, of course, in relation to the disableGroup attribute would be the ability to right-click on the connection status to get a popup list of groups currently busy and the ability to cancel selected jobs

So if I have four buttons: a, b belonging to job group "foo" and c, d belonging to job group "bar", I click on button a and buttons a and b goes disabled. Then I click on button d and buttons c,d goes disabled, then I right click on the connection status and choose "foo" and buttons a,b become available again.

To me, the real issue here is that ICEfaces, in asynchronous operation, can create serious issues for application usability and performance. This is because it does not offer a clear way to suppress (i.e. block) asyncronous operation.
I believe that an application developer should have the ability within the framework to specify whether an operation is asynchoronous or synchronous by nature.
A default implementation of synchronous operation should be offered by the framework, which can be overridden by the developer if required.

Case study: A form lists all records in a table and also shows a detailed view of a record when an item is selected in the list.
In normal operation, a user selects an item from the list and expects to see the details of that item in the form. Ideally this happens instantaneously.
However, latency is significant on a particular system and it takes five seconds to load the details into the form after the event is sent to the server.
In asynchronous operation the user may continue to click on other items in the list. The requests are all queued, and the results come back one after the other replacing the values in the form in succession.
This is a usability issue - the behaviour is not expected by the user and is likely to frustrate or annoy. It is also a serious performance issue, especially in situations where a system which is already suffering from slow performance is bogged down by several more unnecessary requests due to artbitrary user actions.

In this situation it seems clear that the correct mode of operation is synchronous.
A preferable behaviour is to somehow block further user action until the results are returned, or a timeout occurs.

I suggest that in this mode of operation a busy indicator should be shown in the UI and further input (or at least submits) should be denied until the operation is complete. A suggestion of how to achieve this is to include a transparent blocking pane (div) which is enabled during a synchronous operation to prevent any events being sent through to the underlying components. The busy indicator helps the user to intuitively understand that the system is not in the mode of accepting input at present.

this problem also occurs after valuechange events. for example , in selectonemenu. after changing it is value, if submit a button before responce comes from valuechange, all the states gone down. values set wrong components. fresh datas gone .

it is a very big problem for icefaces.

may be this is a solution:

if a range that holds areas which disables first by clicking or after value changes in client side , then it is not important when the responce is come
and responce come, re enable this areas

like a4j , reRender attribute

but the disable operation MUST fired in client side ,

we are making this solution manually,

This issue is partially addressed by the "blockUIOnSubmit" feature added in 1.8. However, that feature has a nasty side-effect of also blocking button action events that trigger a partial-submit on a previously focussed component (see ICE-4308).

We've also had some success with a DoubleSubmitPhaseListener implementation that ignores subsequent submits while the first is processing, but it to suffers from the use-case described above.

We need to review this again, it may be possible to implement a fix that keeps track of the "previous event" and allows onblur events to not block subsequent events – this may actually be a general solution.

This issue is resolved with the fixes for blockUIOnSubmit.