I generally don't think you're wrong, but the tradeoff isn't visible to me given how little programs use Vosk, and even if they use it, it isn't via the C-API. Say the lib becomes more popular over time and speech recognition a less niche thing on Linux, I'm inclined to upstream it.
I still don't understand how this is a "tradeoff". How is changing the VOSK API *less* worthwhile than changing Wine code?
Just keep in mind, what if we want to change to some different lib in the future?
Then it probably won't have the same design flaws as vosk? It seems vanishingly unlikely that we're going to end up reusing this code.
Additionally, I don't want to clutter their API with just some "C-Compatible"/non-Json functions.
I don't see how introducing API bindings that are better for a given language is clutter? I also can't imagine anyone would see this as a *bad* thing. At the very least it doesn't hurt to ask.
I mean, if nothing else, these can be wrappers around existing APIs. That's necessarily true if you're considering doing any of this in Wine itself.
(And one of the two examples that prompted this discussion is an API they already provide for a different language.)