This is a summary of the comments received during the
review of Andrey Semashev's Finite State Machines (FSM)
library. Apologies for the delay in getting these out.

DOCUMENTATION

* Relocate ToC to make it stand out.
* Several people used the Wikipedia article
http://en.wikipedia.org/wiki/Finite_state_machine as
a reference for FSM terminology and operation, and
found discrepancies between Boost.FSM and that description.
Perhaps Boost.FSM should explicitly describe its FSM
metamodel, or refer to an existing metamodel (Wikipedia
FSM or Harel or UML Statechart, for example). The latter
was mentioned several times as being preferred since it
is a standard.
* If possible, use standard terminology. For example,
"transition map" vs. "state transition table". Or
define the non-standard terms.
* Include a comprehensive rationale mapping the design
choices to the design objectives.
* Compare/contrast Boost.FSM with the FSM implementation
as described in "C++ Template Metaprogramming".
* Add an example of event deferral using boost::function.
* Clarify support for multithreading vs. asynchronous FSM,
as some were confused by existing text.
* Clarify lifetime of objects.
* Add implementation of example using transition map/STT.
* Add more complex example(s).

SCOPE/FEATURES

These were features that were suggested or asked about.
Some or all may not be suited for addition to the library.
In that event, it may be useful to explicitly mention in
the documentation that they are not supported, and why.

* Support nested states. Return-to-history was cited as
an example of a benefit of nested states over nested FSM.
* In STT, support matching "any" from state.
* Add syntactic sugar to support "synthetic" states (cf.
http://lists.boost.org/Archives/boost/2008/08/140714.php)
* Support event deferral.
* Support data-dependent transitions (perhaps this is the
same as the synthetic state suggestion above).
* Improve modeling of the "transition" concept. Specifically,
there was an issue with the fact that the action was
associated with a state rather than a transition.

INTERFACE

* There was a lot of discussion comparing the amount of code
required to implement an "ad hoc" FSM, vs. the amount of
code required to implement the same FSM using Boost.FSM.
* The "transition map" representation was deemed to contain
too much syntactic noise and not sufficiently similar to
a traditional STT, and it was suggested that it should
include the transition action.
* Some felt that the interface was too procedural rather than
being declarative.

IMPLEMENTATION

* There was quite a bit of discussion of the Boost.FSM
implementation vs. the C++TM implementation, but I don't
believe there were any specific conclusions reached.
* Handling of event is different depending on whether or not
transition map is used (handled by "to" state vs. current
state, respectively). This is also the case when an event
is not found in the transition map. This could lead to
errors.

Thanks again to Andrey for his submission and to all the
reviewers and other who made comments for their input.