When using the MessagesFile setting in the [Languages] section, it currently does not inherit the ISPP context (defined variables, etc) of the parent script. It would be useful if it did.

As an example, the parent script might:
#define ResourcePath "X:\Some\Path\To\Resource\Files"

And then inside the messages .isl file it could have:
#include ResourcePath + "common-en.isl"

Or one of the messages could use {#SomeVar} as part of its text (though this is only useful for things that can't be translated, such as version numbers or brand names).

I want to password protect uninstallation. So the plan is to ask the uninstall password for it.

No matter what I do, the installation types I have specified are displayed in an order I do not want. I would like to be able to specify that order or at least make one of the types the default selection

As fas as I can tell, there is only one font for the entire setup. I like proportional fonts in general, but the embedded Licence and Information dialogs display a text file in the same which makes it very difficult to format in a small window. Let me choose the font for these dialogs independently.

I want it to be simpler to have a custom icon for the uninstaller

This is a public property value for a feature that is native to the windows installer that simply applies settings (e.g. registry entries) to HKCU for users that have an established profile on the system.

For custom installs where exact installation times may be grossly obscure or otherwise difficult to calculate allow an optional "Marquee Progress" indicator to show the user that the installation is still in progress as opposed to a completed progress bar while there may still be remaining routines to process.

add OpenFileDialog() like function, which will allow user to browse file(s) and select it

When running an installation that is an "update" or "add-on" to an existing installation, we often want to change the minor version number as well. An UpdateUninstallLogVersionNumber=yes would be great.

I think it would be usefull to bind a custom "hint" to every component on component selection page during setup. To display hint for current (selected) component I suggest to allocate some space below or more to the right of component treeview.
This feature is yet implement in NSIS and I think it is enough useful. Without it each component description in treeview become much longer than it might be.

The Format function uses regional settings, eg. Format('%.1f', [1.5]) = '1,5'. But function StrToFloat can not convert such value to string. Instead I have to implement such algorithm:

sTmp := Trim(Edit1.Text);
StringChangeEx(sTmp, ',', '.', True);
nValue := StrToFloat(sTmp);

I would find it helpful if anything that is sent to the log file were also sent to the debug message queue via the OutputDebugString API. It sometimes more convenient to watch the messages unfold in real time.

Ideally, the output would go to the debug queue even if logging wasn't enabled.

Thanks if this is possible.

When uninstalling, StatusMsg is unsupported in [UninstallRun] section. It's inconvenient

I would like to omit the program group selection page, but still allow users to change the group via command line.

There is a shell constant for localappdata, which in win7 gets you to the [userprofile]\AppData\Local folder but none to get you to the [userprofile]\AppData\LocalLow profile space.

Add some type of the callback that will be lauched for a specified files from [FILES] section (marked by some new flag) and provide information: will the Setup replace this file (based on rules, destination etc) or not?
It can more precisely flow the upgrade process. When I upgrade my shell extension but dll file not changed and will not replaced I do not need to restart Explorer process, for example.

I would need to add some resources to the built setup.exe file during the build process.
For instance, I would have to add a "CompatibilityTag" value to the version info.

The compiler allows using Custom Messages using {cm:} constant but lacks access to standard messages, for instance 'FullInstallation'.

There is a possibility to get standard messages using SetupMessage() but it can only be used in [Code] section, it accepts only 1 parameter and this parameter must be an enum (eg 'msgFullInstallation').

To avoid having to duplicate standard messages to custom messages, add a {sm:} constant permitting access to standard messages in the same way as custom messages.

See http://news.jrsoftware.org/news/innosetup/msg90890.html .

The idea is that programs can share a feature with an icon, which stays until all programs have been removed.