One core, two languages
You maintain the same SDK in two or three languages, and the same bug gets fixed separately in each.
Where it goes wrong
Too much goes into the shared layer, and mixing two async runtimes multiplies complexity that belongs to neither team.
By the time any of it hurts, it is load-bearing. Each SDK's users are depending on the surface, every bug in every SDK has become a bug in the core, and the set of people who can fix one has shrunk.
How I'd handle it
I work through the decisions that determine whether this succeeds. Where the line sits between the shared core and each language's SDK comes first, and the binding strategy on each side follows from it. Then build, packaging and release: how the artifacts version and ship relative to one another. That whole workstream gets underestimated, and it is where these migrations stall.
Last, who maintains it afterwards, which is a team question before it is a technical one and is better settled deliberately than discovered later. What you get is a written recommendation carrying the reasoning behind each decision, plus a phased migration plan that keeps both SDKs shipping throughout.
Where I've done this
Band's Python and TypeScript SDKs were to collapse onto one shared Rust core, and they asked me where the line between shared and native should fall. I worked that through with the binding, packaging and maintenance questions that hang off it, and wrote up the reasoning behind each answer for their team to build from.
Recognize this on your team?
Let's talk