P5 is stable as of SR3. Or, more precisely, it is as stable as ProPack, or Poser 4, and I'll daresay moreso.

However P5 does everything at a much higher default/minimum memory footprint. And given that Poser has an excessive memory use, this means that for exactly the same scene, Poser 5 is already much further up the lack-of-memory induced instability curve.

All three versions have the same ongoing issue: if the file reference in the (typically) 3rd party content is wrong, Poser will "hang" while it searches. Slowly. This is a big annoyance, but one that's been around forever. (it's also often called a memory leak, but this is not a leak. Nor is it a logic loop. It's just looking until it gets to the end of the runtime, and then it waits. It eats ram because it stores the info of where its been. Not a leak. Also not poser's fault, although it would be better if it worked differently.)(much better)(Tons better)

Hmm, the invalid file reference and memory leak - or rather leaks - are very different things. Poser 5 has them both, in fact it has all those of Poser 4 plus a few more. The term memory leak referes to a program requesting additional memory allocation from the system, using it, finishing with it (i.e. writing it off witin the program), but forgetting to tell the system, to return it when it's done with it, so it is never recovered (garbage collected) for reuse, by the application or system - until the task ends. Poser 5 adds a monsterous new memory leak of ~4MB per render!

The "hang" following a file reference problem is twofold. It searches the entire Runtime for the missing texture, meaning every single directory, including those that have no right to ever hold a texture. And this means that the textures folder isn't even visited until a huge number of other folders have been pointlesly scanned. But wait, that would just make it slow not fatal, however as Poser (4, PP & 5) open each folder to search the filenames, it conveniently skips the required process of closing them behind it (unless it finds the texture in that one ;-). So the reason it sometimes hangs up indefinitely and sometimes eventually returns to respond to the user, depends entirely on how overstressed the memory footprint was before this texture search cum "let's see how many folders I can open", process started. If you're lucky Poser can survive it, otherwise it'll drive the OS's memory management one huge step closer to an irreversible end (a reason that Poser appears more stable on NT-based OS's - the memory management threshold is higher).