Handle the UnInstall process just like the Install/Setup process using Wizardpages, and the accompanying event functions.
This would allow for a more complete handling of uninstalls, especially when removing 3rd party sub-installs.

I was looking into this last year but kind of put asides for other projects. I really love this feature from MS VS products. Anyway if its been looked into then cool if not I may look into it this year.

When possible, make use of the Windows Vista/7 Task Dialog API instead of MessageBox to show nicer/clearer message boxes.

A real Treeview in the Components List, where subtrees can be collapsed

The compiler should have automatic handling of common pre-requisites such as the .Net Framework 1, 2, 3, 4, MDAC, SQL Server, Internet Explorer etc. This could be activated through a setup directive. The installer should automatically download and install the pre-requisites in the installation process.

There are functions to check the status of components/tasks (IsComponentSelected and IsTaskSelected) by name of it.
It was good to see the functions to change the state of the component/tasks by name(for example, "procedure SelectComponent (const Components: String; State: Boolean );").

You can create Components (for example Main Application, Documentation, Additional Companion Software 1, Additional Companion Software 2, ...), but as far as I know, you cannot provide a description of these components. That would be useful in many setups. It would be useful to tell the end-user what the component is used for, which often is not entirely obvious only by looking at its short name,

Add support to create projects with main iss file and additional files used by #include. I suggest that debug support for included files is very helpful and make debuggin easier than having a debug session on the preprocessed file and fixing in several other files with no navigation support from the preprocessed file to the other file. You are pretty lost in open editors in such a case (default usecase!).

make the ability to show the user the installation process remaining or estimated time.

I know, this is normally done in app but it would be a great FEATURE. The installer could prevent multiple installations or could EXTEND trial with a code. Sure the application would have to call some code that is provided/shared by INNO setup so it can prevent running if trial expired.

See discussion of this over the years:
http://news.jrsoftware.org/news/innosetup/msg23027.html
http://news.jrsoftware.org/news/innosetup/msg56090.html
http://news.jrsoftware.org/news/innosetup/msg62005.html
http://news.jrsoftware.org/news/innosetup/msg57194.html

We have a complex application, with numerous configuration files which are installed by the installation package. If the end-user modifies a configuration file, then we don't want it deleted at uninstall time, and don't want it overwritten by upgrades.

As far as I can tell, to implement this Inno Setup should do a hash of such files, and record it in the uninstall log. At uninstall time, check the file's hash, and don't delete the file if it's changed.

Creation of a Setup Package for our product takes about 15 minutes. Sometimes we need a new Setup with just a few source files changed. Since we have about 8 variants of Setup and Update Packages, it would be very time saving if Inno Setup allows to replace single files within an already created Setup Package. It should work like replacing a file within a ZIP file.

Files generated in the code section by extracting temporary files or just generate files at install should have the possibility to be added to the "known Files" list in unins.dat that the uninstaller can remove them in same manner as files from [File] section. Flaging with "Components" assignment (and other stored in record for files in unins.dat) should be provided by the function.

Right now only the latest [code] section is ran at uninstall time - I suggest adding the ability to run older uninstall-time code going from the latest to the oldest, with each iteration having a way to decide if older version of [code] should run as well.

Add "UninstallSmallImageFile" parameter in [Setup]. Contains file path to the bitmap, which will be showed in top right corner of the uninstaller progress form. Defaults to WizardSmallImageFile.

Actually ExtractTemporaryFile checks only the filename not the path. If you have multiple files with same name on different directories you need to rename files and add DestName parameters to the [files] entries if you need to use ExtractTemporaryFile . With a second parameter (sourcedir) it should possible distinguish different files.

I would like to be able to change the required disk space from code. In other words, if I determine in the [Code] section that the .NET Framework must be installed, I would like the displayed required disk space to change to include the space used by the .NET Framework.

have Inno be able to create patches for files for doing updates during the compile. have the ability to apply these patches created by inno (at compile) without use of DLL during the actuall install.

It would be nice if I could specify a group description for files so that when the installer was unpacking those files it would display the Group Description (instead of rattling -- or as well as -- rattling off the list of file names).

That way the installer could say what it was doing in a user-intelligible way "Installing Core Program Files", "Updating Help", "Fiddling With the Registry", "Reticulating Splines"