Marcus,
I understand your point, however when writing a generic module for SoapySDR like
SoapySDRPlay you have to try to be "everything for everybody", and that
sometimes leads to tradeoff and 'opinionated choices' you have to make in module.
For instance when writing the SoapySDRPlay module, I mostly used CubicSDR as my
'target' application, and in that case we had to make several choices (see for
instance this thread: https://github.com/pothosware/SoapySDRPlay2/issues/62),
which are well summarized in this sentence by Vincent Sonnier, one of the
developers of CubicSDR
(https://github.com/pothosware/SoapySDRPlay2/issues/62#issuecomment-571432329):
I suppose that if we want to plug the square of RSP into the round of a
Soapy module, we must cut corners eventually.
On the other hand, when I wrote the gr-sdrplay3 GNU Radio OOT module, I worked
on the assumption of a more advanced user that wants to have full control of
the capabilities of these RSP SDRs, while choosing sensible defaults that would
still allow anyone familiar with GRC to use them in their flowgraphs easily.
Franco