Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Could you please tell me why the devel_ack- ?

The installer deactivates controls and displays a status message under the control indicating what it's doing for that particular control.  The installer does this in place of switching the mouse to the busy indicator because multiple things are happening in parallel.

For the manual partitioning screen, controls are deactivated in the same style but do not necessarily carry the status message text as you would see on the main hub.  But the paradigm follows from the main screen, controls are deactivated until the underlying task completes.

(In reply to David Cantrell from comment #4)
> The installer deactivates controls and displays a status message under the
> control indicating what it's doing for that particular control.  The
> installer does this in place of switching the mouse to the busy indicator
> because multiple things are happening in parallel.
> For the manual partitioning screen, controls are deactivated in the same
> style but do not necessarily carry the status message text as you would see
> on the main hub.  But the paradigm follows from the main screen, controls
> are deactivated until the underlying task completes.

My report is based on complaints of my colleague Jakub, who didn't see any changes on the screen while waiting more than 10 seconds and trying to click on the UI elements. Do you think this is ok?

The report here is still anecdotal.  You've relayed a personal experience with the installer, which is fine, but there is nothing really actionable in the report, thus nothing to fix.  You may say "well, fix what I saw, I don't like it" which is also fine, but there's not much we can do without a reliable problem description and reproducer information.  There are many many instances where the end user experience in the installer may seem unusual or strange, but nearly all of those are the side effect of external factors (e.g., unresponsive or broken network connection, slow network connections, interrupted network connection, failing hardware and automatic recovery attempts happening in the background, and so on).  All of those types of things combined can lead to odd or peculiar behavior.

All that said, I'll say again that bug reports need to focus on a specific problem and include a reproducer and be something that we can reliably reproduce.  Bug reports that talk about interface redesign or convey opinions about the experience are not bug reports and should be discussed elsewhere.  If you do not want to do that and want to continue filing these types of subjective requests via Bugzilla, understand that we will likely have to close them because they simply aren't bugs.