Description

It's description of Matthew Weier O'Phinney:
"Let's say you have 3 plugins, one registered with no stackIndex, one
with a stackIndex of 99, and another with one of 50. If you register
another, it will get a stackIndex of 3, when it should get a stackIndex
of 1. "

Comments

Postponing to 1.1.0. Right now, I can't figure out a way to do stack ordering that's (a) easily user manipulable (b) maintains reasonable internal index order when indices are automatically generated, and (c) retains backwards compatibility. When I can sit down with the code and ensure (c) in particular can be met, while meeting (a) and (b), we can proceed -- and that will need to wait for 1.1.0.

In our case, the next number represents both the next available positive index AS WELL as the number (if none was provided) of the plugin that was pushed onto the stack. I think this behavior is correct. On the other hand, i think the actual index and top/bottom of the stack might need to be re-evaluated.