I didn't realize just how many functions the API had until now.  I recently started moving all the legacy functions in minisphere into a separate file (to keep the engine and API layer separate), and, well, this is what I ended up with:
https://github.com/fatcerberus/minisphere/blob/master/src/engine/vanilla.c

Note that doesn't even include the map engine functions!

The file currently stands at ~150KB.  The file with the Sphere 2.0 API (pegasus.c) for comparison is around 80KB.  That's a good thing I think: It will lower the learning curve for the new API if there are less functions, and the API will be more consistent because everything was designed together.  Sphere 1.x slowly evolved over time and you can tell by some of the inconsistencies in how APIs are set up.

Yeah, back in 2004 I noticed how long the api was when I was making the python demo for sphere.   But still, 5k lines is not unexpected, the ika source code for the script extension also takes up 5k lines as well, but in their case, it's split up over multiple files. 

As time goes on more and more apis need to be created, that's just to be expected.  The source for script.cpp in sphere v0.75 was only 46k.

The big thing that jumped out at me was that we had lots of graphics functions that could be coalesced, ByteArrays can/should be replaced with ArrayBuffers (ByteArrays were considered a hack by Chad Austin and several others to begin with), and the map engine.

Moving the map engine to script is the logical thing to do nowadays, so that solves that. Using a newer graphics API, or simply condensing the existing graphics functions helps there.

I do think that moving towards a polygon-based graphics API (Galileo-like or otherwise) is the way to go. Although in that case, something like TurboSphere's planned shapelib is a good idea, to easily generate basic shapes like rectangles, circles, etc., since it will help projects get up and running quickly. Likely most projects will move to the raw graphics API at least in part at some point, but it's important to have that first step be easy.

The rest of the API is pretty concise. There are warts here and there, but the rest isn't so bad.

I do think that moving towards a polygon-based graphics API (Galileo-like or otherwise) is the way to go. Although in that case, something like TurboSphere's planned shapelib is a good idea, to easily generate basic shapes like rectangles, circles, etc., since it will help projects get up and running quickly. Likely most projects will move to the raw graphics API at least in part at some point, but it's important to have that first step be easy.

The rest of the API is pretty concise. There are warts here and there, but the rest isn't so bad.

That's actually the purpose of my prim module which I originally linked to in the minisphere thread: It provides replacements for the classic graphics primitives, so that the engine only needs to expose the base Galileo API.

Here it is:
https://github.com/fatcerberus/minisphere/blob/master/assets/system/modules/prim.js

I want to provide several modules like that with minisphere 4.0 so that it's easier for devs to get up and running.

As for ByteArrays, I definitely agree they are a hack and not necessary now that we have ArrayBuffers and their ilk.  minisphere provides them for backwards compatibility only, but they're pretty much deprecated--it's a dark corner of the code that I threw together in a couple hours and don't really bother to maintain.

And yes, the map engine accounts for a huge chunk of the API.  At last count I think it consisted of something like 150 functions.