>>2
Memory management in C is not difficult, even in multi-threaded contexts. You just need to be properly disciplined; let the code exhibit strong proper ownership semantics. Every alloc should be immediately matched with a free so the code is easily auditable. Have thin messaging pipes between threads, erlang-style, instead of mutexes and shared objects everywhere. This is not hard. Comments like "this object is freed by x" or "you should free the returned value" is an indication of bad design. Never return an allocated object with the expectation of it being free()d; instead let the caller allocate it first and pass you the pointer to initialize it, or otherwise wrap alloc+init together and destroy+free together so that the caller code is again symmetric.
Memory management with exceptions in sepples, conversely, is very fucking difficult. A big reason why this is probably the case is because sepples programmers are shitty; they don't understand how important proper object ownership is, so unless you architected the system yourself, the thing is a memory management nightmare. They do stupid fucking shit like wrap everything in shared_ptr and hand them about willy-nilly. Then they wonder why the code is slow and why they still leak when they have reference cycles. I have worked on projects like this in industry before; it's horrible.
I really hope that move semantics fixes this problem in sepplesox. unique_ptr looks very, very good, especially since it obsoletes the boost pointer containers, and move semantics will make it possible to return big data structures by value without performance considerations. Less pointers about is always a good thing.