Hmmm oh, I thought it was generally good practice to make sure the gl_FragColor values are between 0.0 and 1.0.
I don't think it'd hurt to multiply the specular lighting so much but I believe some devices might produce different results if the final value for gl_FragColor isn't limited by 'WHITE'.
I believe keeping the WHITE limit would still produce the same results as now? I'm not sure though

I tried something that worked for me, the difference is the "/" in the filename.
So I suggest you to give this a try:
String shader = new ShaderLocator().getShaderCode("/defaultVertexShaderFog.src");
Alternatively:
final InputStream is = getClass().getResourceAsStream("/defaultVertexShaderFog.src");
String shader = Loader.loadTextFile(is);
Nonetheless, I suppose it would have been nice if the library gave an output of what went wrong instead of crashing on null InputStream...

I think you need to set the shader locator before being able to use it... It probably throws a NullPointerException as a crash now. I'm not sure how this entirely works in the first place either...

I think there should be a way to still access the default shader code. I believe because these shader files are in the base of the jar library, they'd also go to the base of the apk file. I think you should be able to use these shader text files from there.

I believe the best way to alter the default shaders is to re-use them by copying.
That means to extract the jPCT-AE jar using a zip-extractor like WinRAR or something. In here you can find the shaders in plain text.
Copy two shaderfiles (vertex+fragment), which you need, to your Android project.
You can edit these text files and load them into a new GLSLShader as you want.

Okay, thank you for looking into it
I'd be interested in hearing the results.

I'm not entirely sure what you meant with the memory usage thing..? I believe it'd be possible to test it with one single texture assigned to 8 texture layers too. (Not really useful in practice but I guess it's easiest to test)

No idea what that error should be. Something isn't quite right with the gl state for some reason. I would ignore it for now.

Okay, thank you

And yes, 4 is a hard coded limit. I looked into expanding it once, but decided against it for reasons that I can't remember anymore. Must have been a technical limitation of some kind. There's no way to hack around it, I'm afraid.

I found this post (Reply #1) for a possible reason why: http://www.jpct.net/forum2/index.php?topic=3371.0
Another possible reason I could think of: the minimum amount of vertex attributes is used up.

But I still think it should be possible to increase the limit to at least 8; especially modern devices (I think actually old ones too) should support this.
It is true that vertex shaders have very limited textures to access (minimum of 0).
Though, usually I believe textures are only accessed in the fragment shader (so there should be no problem at all considering the limit for the amount of vertex shader textures).
The amount of textures that can be accessed in the fragment shader is at least 8.

To fix the vertex attributes being used up: merge variables into one bigger variable.
Currently there's 4 texture attributes for the texture coordinates (as seen in: http://www.jpct.net/jpct-ae/doc/com/threed/jpct/GLSLShader.html)
However, these are all vec2's, while they could be vec4's.
4 vec4's could potentially hold texture coordinates for 8 texture stages.
Example:
//VERTEX SHADER
...
attribute vec4 texture01;
...
void main(){
    ...
    vec2 texture0 = texture01.xy;
    vec2 texture1 = texture01.zw;
    ...
}
According to the OpenGLES2 spec: https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdf (page 66 of documentation; page 71 of PDF)

State	Minimum value
MAX VERTEX TEXTURE IMAGE UNITS	0
MAX TEXTURE IMAGE UNITS	8
MAX VERTEX ATTRIBS	8

I suppose it'd be a quite a challenge to be rewriting this so I'm not sure if it's too much to ask for.
I'd have wanted to give it a shot if jPCT-AE was open-source but yeah...
Otherwise, would it be possible to add something more hacky so I'd still be able to bind these textures to the Object3D (and its GLSLShader) from stage 5 to 8?
A TextureBindingHook or something for additional texture stages, something like:
TextureInfo blah ... // first 4 textures go here
obj.setTexture(blah);

obj.setTextureBindingHook(new TextureBindingHook(){
    @Override
    public void beforeFinishedBinding(){
        Texture tex = fifthTex;
        int stage = 5;
        String variableName = "textureUnit4";
        methodToBind(tex, stage, variableName);
    }
});
(Additional texture coordinates attributes I don't really need; but only being able to access the textures in the fragment shader)

From my own experience:

Pro's shaders:
Shaders are fastest

Con's shaders:
Shaders can produce inconsistent results on different devices
Writing shaders for animations is more complex than creating Java animations

Perhaps in your situation you could copy and modify the default shader a little to your expectations. It kind of would allow light-manipulation per Object3D once you apply these custom GLSLShaders to different Object3D's. But perhaps a little too complex solution...

Another solution might be to add an IRenderHook to your Object3D's and enable/disable lights in beforeRendering/afterRendering. But I'm not sure if this would work and I'm not sure if this is too great for performance. But in my head, I believe it'd allow for per Object3D (per polygon even...) light manipulation.