Ah, this makes sense

Here is the schematic for Netduino Plus 2:
http://www.netduino....2/schematic.pdf
And here is the schematic for Netduino 3 Wi-Fi:
http://www.netduino....i_schematic.pdf
(Cpu.Pin)0x12 is a direct hardware access mapping to STM32 MCU pin B2.
On Netduino Plus 2, we included a dual-FET on pin PB2 that enabled power to shields. This was a feature exclusive to the gen2 boards. We included that feature mostly to enable low power draws during USB enumeration for compatibility with official USB enumeration current specs, but we found that users overwhelmingly preferred being able to power the board via 3.3V/5V (without reverse-FET power loss) instead. We realized that it was going to be confusing to expose this feature to users, since all GPIO pins would also need to be turned off until the FET was enabled...and so for all the above reasons we removed this FET on gen3 (and focused on adding features and enhancing the power subsystem's raw power and low-current efficiency instead).
On Netduino 3 Wi-Fi, MCU pin B2 is connected to the CC3100's /RESET pin. If you try using that pin from code, either your code or the CC3100 initialization code will fail (due to an exclusive lock on that pin).
Does your project require being able to power up/down the shield on the fly? If so, then the gen2 hardware may be the best pick for your application. Almost all shields are designed in a way which doesn't require changing their power on/off state on the fly, but I know there are always edge cases (and scenarios where you might want to save current).
BTW, once we have Shield Base supported on Netduino 3, you could technically also hack into the FETs that control power to each GoBus port...although we generally recommend against messing with the plug-and-play subsystem.
Does that shed more light on your experience?
Chris