Instructions work well now (I repeated all steps), except step 6 which should read (it missed the “ws” and “gw” parts before):
sudo dnf remove qubes-template-whonix-ws-14
sudo dnf remove qubes-template-whonix-gw-14
Great job and thanks for being so tenacious! 
@Patrick - please publish 0brand’s blog entry once this change is made.
How about this below as a summary of oustanding issues across this thread - many are trivial, not Whonix’s problem, or already partially/fully sorted.
I’ve ignored much earlier stuff about Anon-Connection-Wizard not connecting on first run, since TNT_BOM_BOM, I and others were using old templates & that seems to have been rectified in the latest template:
OUTSTANDING ISSUES
1) Note that the apparmor profile for VirtualBox (when installing apparmor-profiles-whonix) warns:
Warning from /etc/apparmor.d/usr/lib/virtualbox.VirtualBox (/etc/apparmor.d/usr.lib.virtualbox.VirtualBox line 50): Unconfined exec qualifer (ux) allows some dangerous environment variables to be passed to the unconfined process; ‘man 5 apparmor.d’ for details.
Not that I use VirtualBox or care very much, but probably something for @troubadour to consider.
2) No “Connected to Tor” GUI message (from Qubes platform) when Tor connects, as is seen in Whonix 13. Trivial issue and for Qubes devs to fix I presume. Qubes report?
3) Graphical issues inside Dolphin as reported by TNT_BOM_BOM (xfce nautilus interruption?) & Move/Copy to other VMs is not there (presumably a Qubes issue). Workaround: install nautilus. @nurmagoz to report on phabricator?
4) Remove KDE-Help inside GW and WS as it might request suspicious requests which could leak potential data (TNT_BOM_BOM suggestion). @nurmagoz to report on phabricator?
5) To be confirmed: No default shortcuts from Qubes-Whonix toolbar for sys-whonix & anon-whonix (TBC because I may have stuffed up a step - already reported to Qubes Issues). TBC.
6) Tor User Config change “Sandbox 1” (seccomp) to confine Tor process leads to a Tor crash. ConnectionPadding 1 by itself works okay in the config file. Already reported to Tor Project.
7) Template downloads errors - qubes-rpc-multiplexer & verification error on template. @BubonicChronicWhonix to report to Qubes?
8) Onion sources not used by default when upgrading Whonix 13 to Whonix 14 - requires sudo whonix repository --enable --codename stretch. Fixed.
9) The Tor Browser tabs GUI is a little messy i.e. grey and white color instead of just uniform grey. Trivial issue and no doubt related to Debian, Qubes or Tor Project code. Known issue in KDE - probably beyond Whonix scope.
10) Multiple old Whonix builds in unstable Qubes repos. Fixed already.
WHAT IS WORKING
All main things seem to work now with an updated template - who would have thought ha ha 
FURTHER TESTING REQUIRED
QUESTIONS
Should we be seeing many, many socks listeners on ports in the 9000+ range and warnings about “You configured a non-loopback address XX.XXX.X.X:XXXX” in the logs?
Can anybody confirm if you got the defaut shortcuts from the Qubes toolbar in sys-whonix and anon-whonix i.e. did you immediately see Konsole, Anon Connection Wizard etc or did you have to manually add the shortcuts?
Any other problems from testers to add to the above list?
The torbrowser GUI issue (mis-coloring of tabs) disappears if you qvm-copy torbrowser from a whonix-ws-14-based VM to a regular qubes debian stretch VM and then run it from there. So it’s a whonix (or maybe KDE?) specific issue?
Messing with systemsettings5 > Application Styles doesn’t seem to fix it.
The ugly tabs is a known issue on KDE: [PATCH] Active tab looks ugly (inherits system color scheme only partially) (#13818) · Issues · Legacy / Trac · GitLab
sudo qubesctl state.sls qvm.anon-whonix
Even after following steps 5 to 8 as currently written, this command doesn’t create a Whonix 14 sys-whonix.
Prior to running this I had a working whonix-gw with stretch sources.
AFTER the command, I see this error:
whonix-gw: VM directory does not exist: /var/lib/qubes/vm-templates/whonix-gw
Is this just me?
Can anyone who’s followed these instructions check what sys-whonix is actually running.
(If it’s relevant I kept my old templates as -13 versions and retained a sys-whonix-13.)
To make it clear, the command creates qubes named as expected : it creates a sys-whonix but the sources lists are all jessie - i.e it’s a whonix 13 sys-whonix
I did not have this error.
My sys-whonix(14) sources.list shows stretch.
qvm-ls shows sys-whonix is based on what template VM?
I should have said this is on r4.0.
qvm-ls shows template is whonix-gw.
I thought this was a one off the first time but I can reliably reproduce it.
I’m also using r4.0
I ran through the steps again, same results i.e. sys-whonix (14)
Still getting this error? Thats the difference between getting a sys-whonix-13 and sys-whonix-14?
It will be interesting to see results from other testers.
Maybe I’m the odd one out.
I actually saw this problem in R3.2 the second time around running salt. I ignored the problem and configured AppVMs manually, since I though I did something wrong.
Salt is great in theory, but sucks for normal users (like me).
I reckon it is better to point out in the steps that if a user encounters problems with salt, they simply create the sys-whonix ProxyVM and anon-whonix AppVMs manually from Qubes VM Manager, and imitate the network settings as per “old” sys-whonix and anon-whonix i.e. sys-whonix points to sys-firewall and anon-whonix points to sys-whonix.
Sandboxed Tor Browser from Tor Project works in Qubes-Whonix 14! Yeah! Tested with alpha Tor Browser v8.0a5 with AppArmor enforced. This is a major security improvement. 
Now if someone can get the apparmored, sandboxed Tor Browser in Whonix 14 working in a DispVM, you get a cookie 
(Fixed instructions in wiki to: note both platforms work, point to stretch, remove dependencies already installed in Whonix 14, point to latest version of sandbox zip i.e. v 0.0.16 etc).
Connections to v2 and v3 onions etc work as well - just to be sure.
The only thing I wasn’t sure about was after running the “env” command, there is no TOR_CONTROL_PORT=9151 output there.
However, it does show in a couple of places:
TOR_CONTROL_IPC_PATH=/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock
I presume this is good enough to confirm it’s correctly using the system Tor process?
Note also that the sandboxed Tor Browser does not see the Adawaita Gtk theme - don’t know if we give a shit or not to note optional install of it for the wiki instructions. Left it to the user to decide in the wiki instructions.
Done!
@0brand - that’s fine, but you don’t explain how users can tell the difference.
I would not include this but mandate the manual method since we know that salt will fail for some users attempting upgrade. I’ll raise issue against Qubes re salt use.
Added verification instructions. What do you think of adding salt to create VMs as optional - advanced users only! and mandate manual method as primary way to create VMs?
cc// @torjunkie
Edit: I will have the instructions updated a little later on today. This edit was temporary so users know how to verify VMs were Whonix 14 based until I re-write step 8 i.e. salt
if you’re considering not using salt, then why not just update the templateVM setting of the existing sys-whonix and anon-whonix? And they are presumably originally set up the “right” way by Salt.
Otherwise you need additional steps to create new VMs, then duplicate whatever Salt does (e.g. set anon-vm tag to prevent clock correlation, …), and you have to manually set RAM / firewall / NetVM / templateVM settings, yeesh.
Again, if you reuse sys-whonix and anon-whonix, you can upgrade in 4 steps [1]:
No cloning, no renaming, just change two templateVM settings. It’s very Qube-ic.
[1] I also had to fix permissions, in sys-whonix: chown -R debian-tor:debian-tor /var/lib/tor
This way, the steps to install template VMs are tested. This issue would not have been know if Whonix 13 templates were updated to Whonix 14. If a user has to reinstall a Whonix VM template due to VM corruption the step to do so will be sound because they were tested.
Also at the end of the instructions
It should be noted that users also have the option of doing an in-place upgrade of Whonix 13 to Whonix 14, rather than using the release candidate TemplateVMs. If this is preferable, follow the Testers-only documentation at the link below.
Once again, this is testing to ensure everything works as it should. With cloning sys-whonix, how is is known if Anon Connection Wizard works? etc. etc. etc…
I mean “update the templateVM setting of the existing sys-whonix”. I’m not talking about in-place upgrade. I’ve edited my post to clarify the ambiguous phrasing.
Yes I know. I was trying to get the point across that doing things like that, although it may work, does nothing to work the bugs out of installing/configuring etc. Whoinx 14 VMs. I mentioned this to you before.
Just wanted to add:
Its a good idea and it would make the instructions much easy/simpler. However, its important that all the bugs get worked out prior to Whonix 14 being blessed stable. Cutting corners while testing (even if they are Qubish) should be avoided. This way problems will be found sooner rather than later.
P.S. If you would like to help edit the instructions to create Whoinx 14 VMs manually and salt as optional…
Is it really that easy i.e. just switching over TemplateVMs + one permission change?
If so, that’s great @no1.
I also see @0brand’s point, re doing the full blown test to identify any issues across the whole spectrum e.g. as we discovered with running salt twice causing errors i.e. unman and I got that error.
Anyhow, no1’s earlier post pointed out a very serious issue with manual tinkering and not using salt (in Qubes R4 only I think?).
I see in Dev/Qubes it outlines what salt is doing. Most of it expected, except that anon-vm tag stuff. Didn’t even realize that tag existed to prevent clock correlation/time syncing risk!
I understand the tags only exist in Qubes R4 though (?), as 3.2 dom0 doesn’t recognize the qvm-tags command which Rutkowska refers to in her next gen qubes core stack article.
Anyhow, this could be a massive issue and a huge, fat warning might need to be in wiki docs that the (very likely) user expectation of using new whonix-templates to create new sys-whonix and anon-whonix (without resorting to salt) potentially puts the user at risk of de-anonymization, since no anon-vm tag is applied e.g. see here for example:
whonix-ws-based VMs lack the anon-vm tag · Issue #3595 · QubesOS/qubes-issues · GitHub
If my understanding is wrong, please correct me, as I’m not at all familiar with Qubes internals and it is a really complicated black box.