Really, its one or the other by necessity. The things that make a language good for embedding are the opposite of what you want in a general purpose scripting language. Its also unlikely for any language to build great support for c unless thats the purpose of the language (ie, embedding).
Lets consider Lua. Lua uses a prototype based inheritance system and coroutines for concurrency and has basically no standard library. Anyone who uses Lua extensively ends up building their own object/class system in addition to filling out the standard library. This makes sense; an embedded language shouldn't force its object model on its host and it doesn't need a standard library. The host most likely comes with a standard library of its own. The lack of common building blocks and the reliance on external code means Lua will never be a general purpose scripting language because its just too damn hard to reuse code.
The things that make a language good for embedding are the opposite of what you want in a general purpose scripting language
I'm not sure I agree. What you want for embedding is something small, fast, and easily interoperable. What you want for general-purpose programming is powerful, composable abstractions. Lua meets both sets of criteria. It does so by means of exceptionally good design. The fact that it doesn't have the same object model as some other languages doesn't really prove anything, does it? Every well-designed programming language deserves to be thought of on its own terms.
Not having a featureful standard library, on the other hand, certainly is the kind of tradeoff you're talking about. But (a) is it so important to have a standard library as opposed to just pulling in the libraries one needs? and (b) you may be overestimating the difficulty of interfacing with external code in Lua. It's much easier than with other dynamic languages. "Too damn hard" seems an overstatement.
The big question with Lua is whether it's better enough than its peers to overtake them in any area other than embedding. If it is, we should see some sort of killer application of Lua. There is momentum toward an embedded-web-app style a la OpenResty, but also still a high barrier to entry; for one thing, it isn't well documented.
Just like javascript, building an inheritance-based object system in Lua is pretty much the sign that you are fighting the language, rather than using it as it is.
Unlike in javascript, it's possible to build an inheritance-based object system that works almost exactly like Python's in Lua. It's actually a bit trivial. Considering that the language is generally not opinionated even regarding the features it ships with ("you can use 0-based arrays if you want"), this doesn't seem all that bad.
As noted above, when everyone rolls their own object system, integration gets messy. I think it's easier to stick to the basics of using functions and tables.
Lets consider Lua. Lua uses a prototype based inheritance system and coroutines for concurrency and has basically no standard library. Anyone who uses Lua extensively ends up building their own object/class system in addition to filling out the standard library. This makes sense; an embedded language shouldn't force its object model on its host and it doesn't need a standard library. The host most likely comes with a standard library of its own. The lack of common building blocks and the reliance on external code means Lua will never be a general purpose scripting language because its just too damn hard to reuse code.