Yes if the lib is not shared.
Even if it's shared it's not a problem -- each client app use its own pointers and these are passed to server LDG. Of course, the LDG module can't store / reuse it in other places, it must be everytime input data pointer - an operation on it in LDG - output data.
Forget Mintlib there is too much work! It should be better to adapt newlib (http://sourceware.org/newlib/) it is fully reentrant I think
Reentrancy is only one problem of many when it comes to linking LDG+libc, for example WongCK's problem with MagiC will be still here.
Yes probably the best, but not universal (can't work on Magic or TOS), but in fact it could be simply an real ldg sharable!
Yes, kernel LDG support would be interesting thing to see. But as you see, TOS/MagiC are out then, then it's maybe better to use SLB which offer more or less the same and are already available for all 3 of them.
we could in fact create 2 or 3 libc.ldg for each format the choice could be simply done in the client lib. Yes I think this could be an elegant way to solve the problem but we need a reentrant libc.
See above. The problem with MagiC and TOS is in using "dead code". It's described in the (yet unpublished) document I've mentioned, mintlib/newlib/whateverlib is terminated as soon as LDG's main() is done and this leads to all kind of strange problems. Some of them are solved by libshare, some not. New re-entrant libc wont help you with that. Believe me, I've done pretty thorough research on this topic, exporting client's mintlib is the cleanest solution possible.
I was thinking about doing a kind of universal libc wrapper, compatible with PureC, too but I have to think about it yet, not an easy thing to do.