> ok looking at the code I see we have a problem. pick_ori == 'normal' is the LCMV now corresponds to passing a fixed orientation forward in the minimum_norm code. the normal should be selected in W not on G....

To me, passing the fixed orientation forward (i.e. picking the normal orienation on G) is better in the sense that it's the implementation of a scalar beamformer, whereas picking the normal orientation on W is calculating a vector beamformer and only then selecting the normal component. The max-power implementation is now also a scalar beamformer (i.e. in [line 162](https://github.com/rgoj/mne-python/blob/b6d48daae8f84caffc884e9188b258c07185d6f7/mne/beamformer/_lcmv.py#L162)  there is no need to invert Ck because it's just a scalar), only the forward operator is limited to a single orientation later on in the code when it's already included in Wk ([line 153](https://github.com/rgoj/mne-python/blob/b6d48daae8f84caffc884e9188b258c07185d6f7/mne/beamformer/_lcmv.py#L153)) and Ck ([line 154](https://github.com/rgoj/mne-python/blob/b6d48daae8f84caffc884e9188b258c07185d6f7/mne/beamformer/_lcmv.py#L154)). So if we do normal orientation picking we lose compatibility with how max-power is calculated and it's no longer a scalar beamformer even though we're fixing source orientation. WDYT?

I skimmed over this issue (sorry!), but in hindsight it does seem important, maybe it's best to investigate it more deeply, i.e. check what exactly causes the normal orientation to give bigger results - is it really meaningful, occuring where the solutions have large values... or rather only for small values, which would suggest, I guess, numerical issues. I'll try to quickly look into this.