That’s more than often enough, though.
I’ll admit, there have been occasional debates, within the team, as to how competent we are to update and maintain this package (which only debatably forms part of our core business offering). That can has been kicked down the end of the road, but it is an issue worth grappling with at this point.
My read on the situation is that, with two dependencies, this is now a project with value, not purely a “DataPak legacy”. So if it doesn’t make it into the monorepo, it’ll still have to be updated regardless, because now two packages, both with indisputable value propositions, hang on it. There may soon be three or more. I’m not going to say it was an intentional move, but… it was certainly foreseen. No value proposition = cut.
In any case, I do not dictate where this code goes; the above is purely my opinion. But for more than one reason, I am leaning “monorepo”.
That’s probably the easiest question of all time. The priority target for this library is Haiku. The secondary target (from an external perspective) is Windows. There’s not much that could be done to the library to bork it utterly on Windows. If it does get borked, we’ll maintain a patch.
Development of a UNIX counterpart would take effort, and it would be wholly our effort; the only Mac code was for legacy Macintosh Classic.