Do we really need two different types of page flows?
Pageflows started in pages.xml requires a <start-page> as the start of the pageflow. Pageflows started on @Begin annotated methods need a <start-state>. The problem is that you could easily want to start pageflows from either location, and would then need to write two identical pageflows to accomodate this.
i.e. A page for editing a widget is RESTful, and bookmarkable with the id in the URL, elsewhere, you may want to edit the same widget in a nested conversation. as part of another process.
For the RESTFul URL, you need to use pages.xml to define the conversation start and the pageflow.
For the other edit, you need a @begin annotated method (possibly with passing the widget instance in) and it requires a different pageflow, even though it is identical to the first. This annotation is also required to identify the need for a nested conversation.
There is a real need for initiating pageflows from two separate places, and a need for them to use the same page flow. It is possible to work around this and go back to the @Create @Begin(pageflow="editwidget:") annotations on a method for RESTful urls.
Given the number of times the problem appears in the forums, it appears to be an inobvious stumbling block without a real purpose as to its existence.
It just seems messy to have two identical flows, when in 99% of cases the start page/state can be derived from one unified pageflow. In the other 1%, it is still possible to write a separate pageflow, but having two incompatible but almost identical flows appears clumsy.