Include FullAppDir as a variable in PAL?

I was thinking about that, and while it might be good to base ProgramExecutable & ProgramExecutable64 on the location of FullAppDir, it would require changes to a number of app's configurations.
Note: I'm not saying it should or shouldn't be done this way, just that this is a factor to consider.

I think this might be good:

[Launch]
ProgramDirectory=AppName32
ProgramDirectory64=AppName64
ProgramExecutable=Bin\App.exe
ProgramExecutable64=Bin\App64.exe

[FilesMove]
settings\AppSettings.ini=%FullAppDir%\data

matching this structure:

AppNamePortable
+---App
|   +---AppName32
|   |   +---Bin
|   |   |   App.exe
|   |   \---data
|   |       AppSettings.ini (Gets moved here when running on 32-bit Windows)
|   \---AppName64
|       +---Bin
|       |   App64.exe
|       \---data
|           AppSettings.ini (Gets moved here when running on 64-bit Windows)
\---Data
    \---settings
        AppSettings.ini (stored here when not running)

Note: This is a simplified view of the structure, not showing unnecessary files & folders.
Note2: This is intentionally a slightly unusual app in order to show how both FullAppDir/FullAppDir64 and ProgramExecutable/ProgramExecutable64 may be needed in some apps.
Note3: After writing this all out I think I might prefer ProgramDirectory/ProgramDirectory64 as opposed to FullAppDir/FullAppDir64, but I need sleep so I'm going to stop writing. Goodnight.
Edit: I altered my example to use ProgramDirectory/ProgramDirectory64. %FullAppDir% would be built by adding the contents of ProgramDirectory to the end of the %PAL:AppDir% environment variable, and the execution string would be based on the contents of ProgramExecutable being added to the end of %FullAppDir%

That's almost how I went ahead and structured my code. I'm using the variable $Bit to check if file system redirection needs to be turned on or off by using the variable $App and comparing it to ${APP64}. I also use it for checking a machines architecture by doing something like the following in the beginning of the .onInit function:

System::Call `kernel32::GetCurrentProcess()i.s`
System::Call `kernel32::IsWow64Process(is,*i.r0)`
StrCmpS $0 0 +3
StrCpy $Bit 64
Goto +2
StrCpy $Bit 32
!ifdef SYSTEMWIDE_DISABLEREDIR
	!ifdef FORCE_SYSTEMWIDE_DISABLEREDIR
		IntCmp $Bit 64 0 +2 +2
		System::Call `kernel32::Wow64EnableWow64FsRedirection(i0)`
	!else
		StrCmpS $APP ${APP64} 0 +2  ;= If the x64 folder exists in App directory
		System::Call `kernel32::Wow64EnableWow64FsRedirection(i0)`
	!endif
!endif

After all the Segments have been executed I then check and turn the file system redirection back on again:

!ifdef UAC
	${RunSegment} RunAsAdmin		;= Last Segment in .onInit
!endif
!ifdef SYSTEMWIDE_DISABLEREDIR
	!ifdef FORCE_SYSTEMWIDE_DISABLEREDIR
		IntCmp $Bit 64 0 +2 +2
		System::Call `kernel32::Wow64EnableWow64FsRedirection(i1)`
	!else
		StrCmpS $APP ${APP64} 0 +2
		System::Call `kernel32::Wow64EnableWow64FsRedirection(i1)`
	!endif
!endif

I set certain !define instructions that never change in construct using my favorite instruction ( =P ) !searchparse. It only changes with respect for the programs name. For instance, ${APP} will always hold the applications 32-bit folder name (7-Zip or IrfanView) whereas ${APP64} will always hold the 64-bit folder name (7-Zip64 or IrfanView64). If there's a 64-bit version of a program available than ${APP64} is just the short name or the AppID excluding the word "Portable" and appending the number 64. So now I can do something similar to the following code snippet for an application that has both a 32-bit and a 64-bit version (like in my 7-ZipPortable for example):

;= VARIABLES
Var App

;= DEFINES
!define 32     7-Zip\7zFM.exe 			;= These defines are used throughout the custom.nsh file
!define 64     7-Zip64\7zFM.exe
!define EXE32  `$EXEDIR\App\${32}`
!define EXE64  `$EXEDIR\App\${64}`
!define SET32  `Kernel32::SetEnvironmentVariable(t "7-ZIP", t "7-Zip")`
!define SET64  `Kernel32::SetEnvironmentVariable(t "7-ZIP", t "7-Zip64")`

;= CUSTOM
${Segment.OnInit}
	StrCmpS $Bit 32 +6
	IfFileExists `${EXE64}` 0 +5 		;= If user decided to keep the x64 version on install.
	SetRegView 64				;= I can now set the registry view accordingly.
	StrCpy $App ${APP64}			;= $App will now hold whatever ${APP64} is 
	System::Call `${SET64}`			;= Sets %7-ZIP% to contain 7-Zip64
	Goto +3
	StrCpy $App ${APP}			;= $App will be used within the custom.nsh file
	System::Call `${SET32}` 		;= Sets %7-ZIP% to contain 7-Zip
!macroend

Inside my 7-ZipPortable.ini launcher configuration file I may now do the following:

[Launch]
WorkingDirectory=%PAL:AppDir%\%7-ZIP%

[RegistryValueWrite]
HKCU\SOFTWARE\7-Zip\Path=REG_SZ:%PAL:AppDir%\%7-ZIP%\
HKCU\SOFTWARE\7-Zip\Path64=REG_SZ:%PAL:AppDir%\%7-ZIP%\

I'm pretty sure the above code can be done a bit more pragmatically allowing for a much more broad spectrum of portable apps and I realize that you guys I trying to discourage the use of the custom.nsh file but I just felt like sharing anyway. Sorry for going off-topic somewhat with the file system redirection tidbit. I just meant to agree with 3D1T0R and share how I have came to deal with this concept. Lol.

We'll have to check to verify that it works properly first, but with the system Gord & I are considering, you should be able set it to work that way by simply defining [Launch]:BitsVariable32 as an empty string.
I'll try to test it soon, but I'd take a wild guess that Gord can probably get to it sooner than I.

If that doesn't work, then I suppose we could consider having the [Launch]:BitsVariable32 default be an empty string, and if you want it to be 32 (or something else) you have to set it yourself.