TI MSP430 5522 can a watchdog timeout cause SVSL and SVSH POR

Thanks you for the information!

Jens-Michael Gross also provided some great information (I wanted to give him some credit also). His information is below:

SVSL and SVSH are usually caused by insufficient supply voltage. SVSL means the internal regulator was unable to maintain the programmed processor voltage. SVSH refers to VCC input voltage (see the power management chapter in the users guide)
For SVSL, an insufficient supply could be a reason, as well as a missing/broken 470nF capacitor on VCore, or any external load on this pin.
SVSH can be triggered when the supply is instable or has peaks, or if there is no sufficient buffer capacitance on the VCC pins. There should be at least 4,7µF (better 10-47µF) next to the VCC pins, either all on one pin or distributed to multiple pins. While all VCC pins are internally connected, some are closer to this I/O port and some closer to that one, so digital loads on a port pin can cause VCC to drop internally, if the current has to be routed through the internal connections. Well, on a LaunchPad, the wiring should be correct. So maybe the reason is an instable supply, maybe problems with the USB cable, if this is providing power to the board.
Note that USB power is 100mA only by default, and IIRC, the LaunchPads do not apply for more, so if the board consumes more than that in peak situations, this might cause an USB power brownout, which can (due to buffer capacitors) manifest as a voltage dip on VCC (not enough to trigger a real BOR). Just an idea..
Note that the SYSRSTIV register can be read multiple times. It flags all reset reasons since last BOR (brownout/power-on), one after another, but based on priority, not on occurrence. So read this register multiple times until you get 0x00. If you got a WDT reset or a key violation, this should still be reflected by SYSRSTIV, even though the IFG bits have been reset. But I never had this situation myself, and Jeff Tenney (which you quoted) seemed confident that the internal SYSRSTIV bits for them are reset on a POR.
And yes, a WDT reset will simply reset the port pins to input and stop most peripherals (but does not touch the timers!), and then restart your code. It may still be possible that a low voltage condition crashes the CPU and therefore causes a (ignored but noted) WDT reset while the device is still held in POR by the SVS.until the voltage drop recovers or goes deeper to a BOR.
In the cited thread, Jeff Tenney suspected (and I tend to agree) that the PUC initializes the SVS to default values, and if the SVS had been disabled before this may instantly trigger an SVS fault for high and low side because the SVS reference isn't settled. However, this was about the 5438 (non-A) which starts with PMMCOREV = 2 rather than 0 (which is the default for all other 5x family devices). The driver library only raises the core voltage level by level, to prevent a similar problem. However, stepping down from 2 to 0 and re-enabling the SVS during PUC shouldn't cause this. I though this would be a pure 5438 problem due to its unique PMMCOREV=2 initialization.
In any case, if you disable the WDT or do not disable the SVS in your code, this specific problem cannot happen and the SVS resets must have a different reason like the possible power shortage.
BTW: the users guide description is correct. a PUC does not (intentionally) cause a POR.
A BOR resets some registers in hardware (including the SVS). then it starts executing stage one of the boot code. After this, stage two of the boot code (POR) and then stage three (PUC) is executed. It's just a matter of different entry points into consecutive boot code. A POR caused by the SVS will keep the device in POR as long as the SVS fault persists, then begins boot code execution at stage two. A PUC like the WDT will directly jump to stage 3. However, a PUC will initialize some things in the SVS and in the given case, this was triggering a POR and then execute the PUC again. This does not contradict the documentation, even though from a users point of view this makes no difference as the 'offending' code that unintentionally triggers the POR is in the boot code itself.
I just took a look at the F5528 errata sheet (don't have the 5522 errata sheet, but both should be same silicon except for ram size or flash size). Erratum PMM9 looks suspicious.
A PUC (re-)enables SVSL and SVSH. It does not, however, enable SVSLPE and SVSHPE (but these are enabled by a POR and therefore active by default) or configure the SVS. So if you disable the SVS, you should do so in a ways that it still complies with your current operating conditions (e.g. go to the desired operating mode under SVS control, then switch the SVS off). If you don't touch the SVS, then I don't know why a PUC should trigger an SVS event, as it only sets bits that are set by default anyway) and we're back to the supply.
I don't know anything about your code and how you setup the MSP, so I'm just showing up possible explanations without further analysis of probability.

I would also like to give Jens-Michael Gross some credit. He provided some great insight which is below:

SVSL and SVSH are usually caused by insufficient supply voltage. SVSL means the internal regulator was unable to maintain the programmed processor voltage. SVSH refers to VCC input voltage (see the power management chapter in the users guide)
For SVSL, an insufficient supply could be a reason, as well as a missing/broken 470nF capacitor on VCore, or any external load on this pin.
SVSH can be triggered when the supply is instable or has peaks, or if there is no sufficient buffer capacitance on the VCC pins. There should be at least 4,7µF (better 10-47µF) next to the VCC pins, either all on one pin or distributed to multiple pins. While all VCC pins are internally connected, some are closer to this I/O port and some closer to that one, so digital loads on a port pin can cause VCC to drop internally, if the current has to be routed through the internal connections. Well, on a LaunchPad, the wiring should be correct. So maybe the reason is an instable supply, maybe problems with the USB cable, if this is providing power to the board.
Note that USB power is 100mA only by default, and IIRC, the LaunchPads do not apply for more, so if the board consumes more than that in peak situations, this might cause an USB power brownout, which can (due to buffer capacitors) manifest as a voltage dip on VCC (not enough to trigger a real BOR). Just an idea..
Note that the SYSRSTIV register can be read multiple times. It flags all reset reasons since last BOR (brownout/power-on), one after another, but based on priority, not on occurrence. So read this register multiple times until you get 0x00. If you got a WDT reset or a key violation, this should still be reflected by SYSRSTIV, even though the IFG bits have been reset. But I never had this situation myself, and Jeff Tenney (which you quoted) seemed confident that the internal SYSRSTIV bits for them are reset on a POR.
And yes, a WDT reset will simply reset the port pins to input and stop most peripherals (but does not touch the timers!), and then restart your code. It may still be possible that a low voltage condition crashes the CPU and therefore causes a (ignored but noted) WDT reset while the device is still held in POR by the SVS.until the voltage drop recovers or goes deeper to a BOR.
In the cited thread, Jeff Tenney suspected (and I tend to agree) that the PUC initializes the SVS to default values, and if the SVS had been disabled before this may instantly trigger an SVS fault for high and low side because the SVS reference isn't settled. However, this was about the 5438 (non-A) which starts with PMMCOREV = 2 rather than 0 (which is the default for all other 5x family devices). The driver library only raises the core voltage level by level, to prevent a similar problem. However, stepping down from 2 to 0 and re-enabling the SVS during PUC shouldn't cause this. I though this would be a pure 5438 problem due to its unique PMMCOREV=2 initialization.
In any case, if you disable the WDT or do not disable the SVS in your code, this specific problem cannot happen and the SVS resets must have a different reason like the possible power shortage.
BTW: the users guide description is correct. a PUC does not (intentionally) cause a POR.
A BOR resets some registers in hardware (including the SVS). then it starts executing stage one of the boot code. After this, stage two of the boot code (POR) and then stage three (PUC) is executed. It's just a matter of different entry points into consecutive boot code. A POR caused by the SVS will keep the device in POR as long as the SVS fault persists, then begins boot code execution at stage two. A PUC like the WDT will directly jump to stage 3. However, a PUC will initialize some things in the SVS and in the given case, this was triggering a POR and then execute the PUC again. This does not contradict the documentation, even though from a users point of view this makes no difference as the 'offending' code that unintentionally triggers the POR is in the boot code itself.
I just took a look at the F5528 errata sheet (don't have the 5522 errata sheet, but both should be same silicon except for ram size or flash size). Erratum PMM9 looks suspicious.
A PUC (re-)enables SVSL and SVSH. It does not, however, enable SVSLPE and SVSHPE (but these are enabled by a POR and therefore active by default) or configure the SVS. So if you disable the SVS, you should do so in a ways that it still complies with your current operating conditions (e.g. go to the desired operating mode under SVS control, then switch the SVS off). If you don't touch the SVS, then I don't know why a PUC should trigger an SVS event, as it only sets bits that are set by default anyway) and we're back to the supply.
I don't know anything about your code and how you setup the MSP, so I'm just showing up possible explanations without further analysis of probability.