I've been eagerly anticipating the new version of Spirit ever since BoostCon 07. I've been using the code from the release branch to play around with it a bit, and I have a few concerns about its usability. I specifically have been using it to replace some rather ugly parsing code in an existing library. This code parses tagged text for use in a GUI, e.g. "Some text, <i>partially italicized</i>." This is very similar to the mini_xml example in the docs, so I used that as a starting point. There are some key differences between the simple_xml format and my needs, and as soon as I started deviating from the example too far I started having troubles. The differences are: 1) A tag can have parameters, and they don't look exactly like xml attributes, e.g. "<color 255 255 255 127>translucent white text</color>". 2) The "<pre>" tag is special. It turns off recognition of all future tags until the next "</pre>" end-tag is seen. 3) Stray "<" characters in the non-tag parts of the input are fine. 1) and 2) were fairly straightforward to implement as changes to simple_xml, but 3) has so far eluded me. 3) requires that all ">" sequence operators be changed to ">>" in the tagged-text parsing, so that more extensive backtracking can be done to ensure a stray "<" is not actually part of a tag. I'll summarize briefly the problems I had in terms of surprises, counterintuitive interfaces, and compilation failures that left me nonplussed. I've attached the full source (only one file, called "test.cpp"), and there are numerous comments in that code that are more direct and explicit. All my efforts were done with various recent revisions, most recently HEAD at the time of this writing -- 47802. Everything was done on a Linux box with GCC 4.1.2. - Auto-assignment seems to work fine for simple expressions, and fail for only slightly more complicated ones that the user would not expect. See Line 61. - Alternative expressions do not seem to work in a greedy fashion in all cases. See Line 70. - The rules for whether a character parser has an attribute or not are sure to seem arbitrary to everyday users. See Line 83. - In at least one case, a rule whose attribute was explicitly declared to be a type I defined (TaggedText) stubbornly insisted its attribute was std::string. See line 117. - Changing the ">" sequence operators (which seem to work nicely with "%=") to ">>" sequence operators makes the use of "%=" produce compilation errors. This forces one to resort to using semantic actions like in Spirit 1. See Line 124. On a different note, two of the Qi examples do not compile. They are actions and calc3_lexer. I did not try to compile the others (Karma, etc.). All tests (for everything -- not just Qi) pass. Zach Laine