Sharing my experience, as some of these are likely to be in common with other users.
I elected to do a fresh install of 4.3 rather than an in-place upgrade. Installation was clean, no problems.
1. Warnings in initial Qubes Update of the starter templates:
Noticed a few warnings, nothing I have investigated yet as they don’t appear to be dire.
debian-13-xfce:
/usr/lib/python3/dist-packages/apt/cache.py:410: Warning: W:Download is performed unsandboxed as root as file '/var/cache/apt/archives/partial/firefox-esr_140.6.0esr-1~deb13u1_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
res = fetcher.run()
debian-13-minimal:
...
/var/lib/dpkg/info/qubes-core-agent.postinst: line 191: glib-compile-schemas: command not found
...
/usr/lib/python3/dist-packages/qubesagent/test_firewall.py:146: SyntaxWarning: invalid escape sequence '\d'
self.assertIsNotNone(re.match('^\d+\.\d+\.\d+\.\d+/32$',
/usr/lib/python3/dist-packages/qubesagent/test_firewall.py:149: SyntaxWarning: invalid escape sequence '\d'
self.assertIsNotNone(re.match('^[0-9a-f:]+/\d+$',
...
2. Qubes Backup Restore:
I hung myself by removing the dom0 ~/QubesIncoming directory after starting a partial restore. qubes-backup-restore uses this directory as workspace- don’t remove it. 
Reported: `qubes-backup-restore` maybe shouldn't hide the working files it places in `~/QubesIncoming` · Issue #10551 · QubesOS/qubes-issues · GitHub (and a mitigation submitted by @alimirjamali within hours)
3. Restored Whonix app qubes need a minor intervention
After switching any restored anon-vm qube from template whonix-workstation-17 to whonix-workstation-18 and booting it up, a repeated notification:
Denied sdwdate-gui.ConnectCheck from <anon qube> to sys-whonix
This is because the qube needs a new tag sdwdate-gui-client under Whonix 18. You can add the tag yourself: qvm-tags <appvm> add sdwdate-gui-client; or restart qubesd: [user@dom0 ~]$ sudo systemctl restart qubesd.service, or reboot the machine, and the missing tag will be added to the app qube/s automatically.
4. Permission denied error when trying to run update-torbrowser:
See:
[user@dom0 ~]$ qvm-run --pass-io -u user whonix-workstation-18 '/usr/bin/update-torbrowser --onion --only-if-newer --noask --noaskstart'
INFO: ARCH 'x86_64' detected.
INFO: ARCH_DOWNLOAD 'linux-x86_64' detected.
INFO: CURL_PROXY: '--proxy
http://127.0.0.1:8082/'
INFO: Automatically setting download folder to '/var/cache/tb-binary', because running inside Qubes Template but not run from postinst. This is useful so you get up to date versions of 'Tor Browser' in newly created App Qubes inherited from updated Templates.
More info: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Qubes-specific
INFO: TB_FORCE_INSTALL is set to '1', therefore setting TB_INPUT to 'none'.
rm: cannot remove '/var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder': Permission denied
The cause is the -u user, which was okay for Whonix 17 but on Whonix 18 update-torbrowser should be run by sysmaint. Just leave off the -u user and sysmaint will be selected automatically:
[user@dom0 ~]$ qvm-run --pass-io whonix-workstation-18 '/usr/bin/update-torbrowser --onion --only-if-newer --noask --noaskstart'
5. No more Thunderbird by default in Whonix 18
Context: Whonix 17.4.4.6 - Point Release! - News - Whonix Forum
You can still install the thunderbird package to get it back. Maybe it’s time to switch to mutt?
6. Restored sys-pihole appeared to stop forwarding traffic:
My Debian 12 sys-pihole standalone, based on @unman’s package, appeared to have stopped functioning after restoring from backup onto 4.3. The smoking gun was in the console output of the upstream mirage-firewall netvm:
<timestamp>: [WARNING] [dispatcher] Incorrect source IP 10.137.0.140 in IP packet from 10.137.0.20 (dropping)
<timestamp>: [WARNING] [dispatcher] Incorrect source IP 10.137.0.140 in IP packet from 10.137.0.20 (dropping)
<timestamp>: [WARNING] [dispatcher] Incorrect source IP 10.137.0.140 in IP packet from 10.137.0.20 (dropping)
<timestamp>: [WARNING] [dispatcher] Incorrect source IP 10.137.0.140 in IP packet from 10.137.0.20 (dropping)
<timestamp>: [WARNING] [dispatcher] Incorrect source IP 10.137.0.140 in IP packet from 10.137.0.20 (dropping)
The sys-pihole qube believed it had a different IP than it actually did. This I think is because the qvm-prefs sys-pihole ip value changed in the restored qube compared to the original qube. The pihole network config needed to be informed that its IP changed.
Here’s a little script that does that:
#!/bin/bash
set -euo pipefail
set -x
QUBE=sys-pihole
qubes_ip=$(qvm-run -p -u root "$QUBE" 'qubesdb-read /qubes-ip')
qubes_gateway=$(qvm-run -p -u root "$QUBE" 'qubesdb-read /qubes-gateway')
echo "auto eth0
iface eth0 inet static
address ${qubes_ip}
netmask 255.0.0.0
gateway ${qubes_gateway}
" | qvm-run -p -u root "$QUBE" 'cat > /etc/network/interfaces.d/eth0'
7. devilspie2 / xfwm4 behavior change
After installing devilspie2 some of my window scripting was not functioning right. It used to be that the get_application_name() lua function would return the terminal title (as from echo -ne "\033]0;blah blah blah\007") when run on a terminal window, but after some recent-ish change in devilspie2 or in the XFCE window manager, this function returns the name of the terminal executable instead. The fix was to use the get_window_name() lua function for this, as it is returning the terminal title in 4.3.