Installing application for currently logged in use

A very common question about creating (Inno Setup) installers revolve around accessing/modifying a profile of a specific user (the currently logged in user) from an installer that runs with elevated/Administrator privileges.

Doing this has many drawbacks and is error prone.

All the existing answers cover part of the problem (registry, files, desktop icon, etc). A purpose of this question is to collect answers that address the problem globally, with all possible approaches.

Inno Setup does not have any built-in mechanism to access or modify user environment from installer running with elevated/Administrator privileges.

All the attempts to achieve this rely on tricks like:

runasoriginaluser flag or ExecAsOriginalUser function. Some examples:

Modifying or accessing registry of logged in user:
Inno Setup Creating registry key for logged in user (not admin user) or
How to read registry HKCU for logged In user from Inno Setup installer running as administrator

Accessing AppData folder of logged in user:
Inno Setup always installs into admin's AppData directory or
Inno Setup Using {localappdata} for logged in user or
Inno Setup - puts user files in admin documents.
or using {user*} constants.

Though these are not reliable, at least for these reasons:

When the current user does not have Administrator privileges, (s)he needs to enter Administrator credentials on installer UAC prompt. That switches the installer to a different user. So {user*} constants will not refer to the user that initiated the installation.
When the user explicitly runs the installer with elevated privileges, e.g. by right-clicking the installer and selecting "Run as administrator" or running it from another elevated application (file manager), the "original user" for runasoriginaluser flag or ExecAsOriginalUser function will already be elevated.
In corporate environments, applications are installed by Administrator, who is not the user that will be using the application.

The only correct generic solution to this problem is to defer a setup of the user environment only to the actual user session.

Easiest is to have the application itself do the setup on its first run.

The installer can only deploy shared files that the application can use for the setup.

If you cannot modify the application for whatever reason, you would have to iterate all accounts and modify them:

for files: Inno Setup Create individual shortcuts on all desktops of all users
for registry: Uninstall auto-run registry entries for all users

If you need to make sure the settings get distributed to accounts that get created only after installation, see How to install files for each user, including future new users, in Inno Setup?

If you are happy with a fact that the application will be setup for the logged in user only, use PrivilegesRequired=lowest:

[Setup]
PrivilegesRequired=lowest

Then the {user*} constants will correctly refer to the current user's folder.

If you still need Administrator privileges for some sub-task of the installation, you can requests privileges elevation for the sub-task only:

Inno Setup - Register components as an administrator
Inno Setup - Access unprivileged account folders from installer that requires privileges

If you want to prevent user from breaking this by explicitly running the installer with Administrator privileges, see

Can't get Inno Setup postinstall Run item to runasoriginaluser or
my answer to How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.

Or you can programmatically find out, what if the account of the current Windows logon session: