The issue is that folder_iterators (and message_iterators) are what's called
proxy iterators. Their operator* returns by value, constructing a new object each time it's dereferenced.
In your first example, you store off the result of *iter in a folder object. This is good.
In your second example, you're derefencing the folder iterator multiple times (in the message_begin and message_end call). Each deference returns a
different folder object, and as such their iterators are not comparing equal, so you're walking over the end of the message range.
Basically, we don't actually have a collection of folder objects or message objects in memory to iterate over, like we would if they were in an STL container. The number if potentially unbounded, and we have to do disk I/O to construct that list. To be performant
we have to construct them on demand as the iterator is moved through the file.
So how to do that is a design issue. An alternative design would call for the iterator to keep a local copy of the folder object it points to and return a reference to the same copy on each dereference. This has this problem though:
folder& f = *iter; // f is a reference to whatever iter points to now
wcout << f.get_name(); // works as you'd expect
wcout << f.get_name(); // not the same as above!