I've been a bit delayed in replying to this thread, preferring to work forward than talk too long. Admittedly, at the same time, other projects took priority for a while. The other project member is not so active at this point. I have many ideas to formalize before heating the debate too far.
I'll address a few points though:
There should be a hardware abstraction to allow portable physics programming among physx processors, GPUs, and CPUs (maybe cell processors too?).
The motivating problem is already here. Groups at UNC and elsewhere have been using GPU's for collision detection computations in a language that is entirely not in terms of physics. We aim to alleiviate this and let physics programmers write code in terms of physics, without any graphics knowledge. Havok has also demonstrated collision detection on the GPU, but not on PhysX. Likewise, Novodex demonstrated collision detection on PhysX but not GPU.
The intended goal is as low-level as possible while abstracting away the specific underlying hardware. This should not threaten the existence of any middleware, but instead offer middleware authors further options and portability. We should also skim under the level of proprietary physics algorithms, instead providing the building blocks and primitives that could implement them.
Still, it is worth consideration to optionally expose underlying hardware to allow for specific optimizations. In general, the exposure should be a convenience to users, not a necessity for use.
A programmable pipeline is definitely a requirement, as well as a basic default pipeline implementation for convenience.
We have to be careful not to say this is intended only for game physics. It could also be of interest to the research community and other industry segments that are concerned more with accuracy before speed.