DeleteAtUninstall=False seems to require AlwaysCreate=True and no actual
registry items to be installed. The only time it seems to leave the key
behind is when there are no registry items under the key,
DeleteAtUninstall=False and AlwaysCreate=True.  So these two settings
control whether keys get created and uninstalled when there are no
suboerdinate registry items (because by default keys wouldn't get created if
there are no subordinate registry items).

Hello all.  I came across this same issue while making installers using
visual studio .net 2k5 deployment projects.  I may have a workaround that
might work for you.   The problem I have is that I create an initial version
of an application which creates registry settings in the installer.  When I
release an update to the program, I want to add the values if they are not
there but do not want to change them if they are already there in case they
were modified by the user of the installed program.  As we have all
discovered, the DeleteAtUninstall property just does not work.  It will
remove the settings regardless.  If you want to install a new version,
setting the RemovePrevious option will uninstall everything and reinstall the
new version wiping out your original registry entries.  The only way to work
around that is to set the RemovePrevious property to false and set install
conditions on the registry entries to not create them if they are there.  But
that results in another entry in Add/Remove programs for each update you
install.  The users do not like to see 5 versions of the same program in
Add/Remove programs as it clutters things up.  So I think I have a
workaround.  It does have a drawback however.
In your application's registry settings, set up a key named INSTALLED and
give it a value of 1.  Then a little trick to hijack an installer property to
cause subsequent installations to NOT show in Add Remove Programs.  Create a
registry search condition that assigns the value of the Installed registry
key you created to the ARPSYSTEMCOMPONENT property.  The way it works is like
this.  The first time you install the app, your registry key you named
installed will not exist.  The registry search will assign the "" to the
ARPSYSTEMCOMPONENT property which will cause it to create an entry in Add
Remove Programs.  A subsequent installation of a new version of the app will
work like this.  Since you already installed the first version and created a
registry key of INSTALLED with a value of 1, the registry search will find
this value on a subsequent install and assign it to the ARPSYSTEMCOMPONENT
property.  This will prevent the entry from being recreated in Add Remove
Programs list.  The second problem is that if you do not want to wipe out
your registry entries each time it is reinstalled, you have to create a
registry search for each key that you want to preserve.  This is a pain.  I
found a way to work around that as well.  Have your installer create a
registry entry named VERSION1 and assign it a value of 1.  Then create a
registry search called Version1 that looks for this registry key and assigns
it's value to a VERSION1 property.  On the conditions for the registry entrys
you can put VERSION1<>1 for the condition.  The first time your installer
runs, the VERSION1 registry entry will not exist.  When an updated version is
installed, the VERSION1 key will exist from the first installation and cause
the registry search to assign the value 1 to the VERSION1 property.  This
will prevent it from wiping out your version 1 settings.  Then if you need to
add new settings in an update installer, create a VERSION2 registry entry and
set it to 1 and create a registry search that assigns the value of the
VERSION2 registry key to the VERSION2 property.  This way, when you install
version 1 over version 2, it will not recreate the version 1 entries but
since the VERSION2 registry key does not exist, the registry entries that
have a condition of VERSION2<>1 will be created.  That way if a user
downloads version 2 of your installer without having version 1 installed, it
will install both of the VERSION1 and VERSION2 keys since their registry
entries do not exist.

I know this is pretty convaluted but it does work.  The only downside is
that when an update has been installed and the user uninstalls the 1 entry in
ADD Remove programs, it will not remove the registry entries, directories,
and files from the user's computer.  You can go to the Windows\installer
folder and find the .msi for the hidden updates and right-click and click
uninstall and it will remove ALL of the entries, files, and folders.

If anyone has a better workaround I would love to hear about it.  It seems
that Microsoft in their infinite wisdom has overlooked a common scenario that
is faced by many developers.  Their desire to "Force" you to do things in the
way they deem appropriate just causes us to have to do crazy things such as
the workaround I suggest.