Providing multiple API's does not reduce your own projects ability to reuse its own code between those API's (when well engineered), nor does it limit the ability to share code between projects (otherwise we would have to rewrite the operating system each time we make a new program).
I'm going to rephrase your question as:
Does providing multiple API's limit my clients ability to share and reuse code?
Short answer: no.
Longer answer: Other stuff does, not the number of API's.
Reuse itself has no technical barrier that cannot be easily overcome. Particularly in this day and age.
There are many libraries out there that allow one language to call into another*. This might be done by interpreting the other program (embedded put-on, lua, tcl, etc... (even c)), or by marshalling the call across to the compiled component such as by JNI, COM, HTTP, SOAP, etc..., or even by directly/dynamically linking the component.
Even if the component does not already support it, it should be reasonably possible to provide a shell for the component which allows shell scripting (available from any desktop/server language) to work with it.
So from a user perspective, there is no technical reason why they could not share their nice script, with someone else who wishes to use it.
The main issue is in fact the issue of any public service/library maintainer. When you share code there are a number of incidental responsibilities.
- It needs to be reliable - This code is being depended on, it must work, or reasonably fail.
- It needs to be stable - Updates should preserve the interface behaviour. Breaking changes should be flagged, have work-arounds, and migration paths.
- It needs to be documented - You can't use even the nicest script without knowing how.
- It needs to be maintained - Bugs happen, Vulnerabilities are discovered, upstream systems change. These have to be solved.
- It needs to be distributed - Code that you can't access is unusable, whether behind a service, in a binary, or as source.
- It needs feedback loops (a community) - Code is just an artefact of a community of individuals who know the problem being solved, that is the most important thing ever. The code is just the best guess at a solution.
I would not consider making my software dependent on other software that does not have at least these incidental properties. As an API provider you are aware how non-trivial these things can be.
If your own clients ability to share code is crucial to your platform/application. Consider offering GitHub like services, or some form of package manager. This would reduce the burden of these incidentals on the downstream developers, while also reducing the burden on their clients. It would additionally improve the sense of community around your own software, bringing those individuals into contact with each other. They will figure out how to specifically reuse each others code.
*Side Note: C can embed a fully featured python environment, and Python can easily be extended by C libraries.