Is this really a fatal error? Shouldn't the functionality be disabled instead?

good question.
VPL on linux doesn't work on CPU. So without VA_API it is useless
What do you think - should we allow to configure VPL without VAAPI for now?

let's put it as is for now. Later we added dynamic plugin feature which will rewrite this Cmake part anyway
What do you think?

ok, will see

We should absorb all this complexity someday. User apps shouldn't be that complicated to use a VA path..

I put comment above:
https://github.com/opencv/opencv/pull/22212/files#diff-b4563bcdbe86eb5c8f1f2cce227809b02980777b25f5f4be2bb717826bedbebbR414

The idead behind the current sample is demonstration of the most complex way how to use VPL with GPU. This complexity represent a way HOW-TO-CHOOSE-SUITABLE-GPU from multi-acceleration hardware setup. When you have two or more GPUs then it should provide stable and clearest way how to enumerate them and use as pipeline accelerator.

Additionally, user might got their own framework/pipeline which uses PREdefined GPU device from own framework primitives AND i do not see reasons why we should not REuse this straight device handle with native API instead of using VPL/GAPI "default" one (simplest but not worth way). IN more complicated case use-predefined GPU might be differen when VPL/GAPI/IE recreate it by itself by using "default" selection. S0, for REAL scenarious (not synthetic one) we must implement accepting user-defiend device like these

So, I had intention to explain the most customizable scenarion by this sample (which is trickly and maybe complicated for newcomers), because the default GPU device selection is pretty simple: just invoke default onevpl::GSource ctor with like this:

auto s = onevpl::GSource( CfgParam {"mfxImplDescription.AccelerationMode","MFX_ACCEL_MODE_VIA_D3D11"});

If we have all this code here, why do we have it in the sample app as well?

this is "default device selection" part - for use-cases when we do not want to choose suitable GPU device for Source and just select the first one. It's according to the "simplest sample" configuration, which is not interesting case as sample, as for me :)

Please, check out comment in sample: https://github.com/opencv/opencv/pull/22212/files#diff-b4563bcdbe86eb5c8f1f2cce227809b02980777b25f5f4be2bb717826bedbebbR414

The current "complicated" sample demonstrate how to assing user-selected device for GAPI-pipelien: source, preproc, ie. The sample demonstrates this extended API usage using first-device in sample as "custom device". Therefore this "device selection part" is mostly the same in here and sample

In other words:
it is possible for using simple sample with auto selection GPU device by oneVPL source (you commented the right line for default device selection part)
But this simple demonstration sample for GPU will cause questions from intermediate users whos have got a mulltiple GPUs - like How-To-Use-My-Specifc device.

So, It is possible to anticipate such questions and provide complete example - "complicated sample" which uncover these questions. And because this samples demonstrates an interface with idea of fine-grained device selection - it doesn't matter ( from sample point of view) how specific device will be selected: it's assumed that user have one. Thus default device selection part is the same: in sample and in default-branch of cfg_param_device_selector

Abstraction leak, isnt it?

?
Would you be kind to clarify your point?