In that case, if header-only is outside the scope of the license, it begs the question why they would pick that license in the first place. But anyways, it doesn't seem clear from the passage how headers fit in, considering that these headers are not just APIs, they contain the implementation themselves.
In this case I interpret LGPL as "Please don't maintain your own fork (with bugfixs) in your company internally, contribute to my repo directly", which make sense.
This was indeed what I was thinking in the first place, when I made VkFFT - your project doesn't have to be open-source, but please share your modifications to VkFFT. I think about switching it to MPL 2.0, is this one better for everybody?
Yes, I believe the MPL fits the usecase you describe.
As far as I understand it, proprietary code using an LGPL licensed library is more or less incompatible with templates in header files (!!!) since there's no way (AFAIK?) to relink against a modified version without providing your full source code. Supposedly the LGPLv3 provides an exception for header files but personally I wouldn't go anywhere near it because it seems quite vague - "small" macros, templates that are less than 10 lines (what constitutes a line?) etc.
So as currently licensed (LGPL), I don't think your library is usable as part of a proprietary project.
The MPL, in contrast, places no relinking requirements on the developer. You only have to share any changes you happen to make to the MPL licensed code.
It doesn't "beg the question" (that being the name of a logical fallacy), but does invite it.
Sometimes LGPL is chosen out of confusion, sometimes symbolically. Whatever the legal demands it does not impose, it would be rude not to honor its intent.
