Full ACK
I will try to take a look at what is going on, but the whole business is a little murky to track through the code. (this is mostly due to effects in different sectinos of the GUI and exceptions on how things work on macOS)
Okay, here we go. Let’s work backwards from the end.
One of the last steps in the RT pipeline is a transformation from Lab back to RGB (code in dcrop.cc here).
If the internal variable monitorTransform is set, it uses lcms2 to apply a specific transformation on the Lab data. This variable encompasses several options (see below). The transform returns RGB data in the desired color space. If the variable is not set, the Lab data is converted to sRGB assuming a D50 illuminant (code in iplab2rgb.cc here). This actually seems a little strange, since the selected ouput profile is not taken into account (as far as I can tell…).
The monitorTransform variable is set in the updateColorProfiles function (code in improcfun.cc here). This is where everything comes together I believe.
If a monitor profile is set and softproofing is enabled and a printer profile is set, RT constructs a transformation based on the printer profile and takes into account black point compensation and rendering intent (set in Preferences). For this it uses the lcms2 function cmsCreateProofingTransform (see page 85 of the lcms2 documentation), so the monitor profile is taken into account as well.
If a monitor profile is set and softproofing is enabled and no printer profile is set, RT does the same, but uses the selected output profile instead. (Again, the monitor profile is taken care of as well.)
If a monitor profile is set and no softproofing is enabled, RT creates a transform only based on the monitor profile using the cmsCreateTransform function. Here the black point compensation and rendering intent are also taken care of.
The gamut check always respects whatever choice of profile (softproof, monitor or none). It does exactly what the tooltip says (code in gamutwarning.cc here).
Edit: I’ll leave it to you guys to figure out whether the tooltips or documentation needs an update!
I inspected the code and detected something wrong, though not related to gamut button, but related to the button for histogram view:
If the button is pressed, the histogram is shown with respect to the primaries of the working profile, but the power (gamma) used in this case always is 2.2 (sRGB), while for example ProPhoto has a power (gamma) of 1.8
Thanks, @Thanatomanic to take the time to dive into code and explain us.
I have to read carefully what you wrote.
When clear with above, and after proofreading rawpedia on that subject, I will open an issue to propose, if needed, addition of explanations in rawpedia and modifications of tooltips.
If somebody feels enthusiast to do that, of course he is welcome 
@heckflosse
The gamma 2.2 is introduced by design and has has no relation with the real gamma or TRC of the basic color profile
I think the gamma 2.2 is applied to help to get about the same shape for the WS histogram and output histogram. Ah! it’s not true if the output profile is linear.
for the other views ( parade, waveform, vectorscop), I don’t know if it is applied.
As the working space is always linear( even if the basic space as ProPhoto is non-linear), I think applying a gamma can mislead users when looking to rgb values with the pipette or looking at histogram.
For my part I would like that this gamma was not used for WS values.
I agree, but currently it’s this way for the histogram when viewed in WS mode.
The documentation does need a revamp… The tooltips need to be improved.
FWIW, there is an updated explanation in Spanish. It is just there if somebody wants to use that information and write a proper English update.