This fixes the oversights I mentioned previously. Setting the sprite name is no longer omitted from the instructions, and I also added support for case-sensitive file systems, which I imagine most of you are using. It now does a simple test to check whether or not filenames in the output directory are case-sensitive. If they are not, it creates frames 'a' and up in a subdirectory so as not to overwrite the frames with uppercase letters.
Also, I just found out about application templates in Blender. The next version will likely be installed in this way. That will make it conveniently accessible via the File->New menu. This should also make it possible to improve the UX for the batch rendering process; I imagine I'd be able to add a button in the Render panel for it or something.
The batch-rendering process has been overhauled. It's no longer tied to animation frames, meaning you can now use keyframe interpolation in animated sprites with multiple angles. Instead, a Python script is included in the .blend file, which will automatically render every angle of every frame, even using the correct filenames. It's somewhat rough on the edges, but it should work well enough.
I've included a material node group which will automatically fit a shader output to a range of colors on the SRB2 palette (which is visible on the Shading tab for reference.) I've also included some sample materials in different colors that use this node, as well as adding a new part to the sample model which uses a few of these materials. While it should be possible to use this for the player color range, I haven't changed that material to use it, simply because "if it ain't broke, don't fix it."
This isn't new to v2.0 per se, but this version includes the compositing change from 1.1a.
EDIT: Not sure how to actually post the updated version; I'll upload it once I know how, which shouldn't be long. It's up now. Thanks for your help, SeventhSentinel! EDIT3: I just realized, I missed a step in the instructions. I'll fix that when the next version is uploaded, but in the meantime, the missing step is to set the "Sprite Name" parameter in the custom properties. Also, I just realized there's an oversight in the Python script which will probably prevent a significant portion of users—specifically, anyone using a case-sensitive filesystem, which is the default in Windows—from exporting animations with more than 35 frames. This is because some of the frames' names differ only in the use of upper- vs lowercase letters.