1. Tree equivalencies. Currently, /contend/ /content/ /resend/ /resent/
produces (?:conten[dt]|resend[dt]) but it is possible to produce
(?:cont|res)en[dt] if one can spot the common tail nodes (and walk back
the equivalent paths). Or be by me my => /[bm][ey]/ in the simplest case.

To do this requires a certain amount of restructuring of the code.
Currently, the algorithm uses a two-phase approach. In the first
phase, the trie is traversed and reductions are performed. In the
second phase, the reduced trie is traversed and the pattern is
emitted.

What has to occur is that the reduction and emission have to occur
together. As a node is completed, it is replaced by its string
representation. This then allows child nodes to be compared for
equality with a simple 'eq'. Since there is only a single traversal,
the overall generation time might drop, even though the context
baggage required to delve through the tree will be more expensive
to carry along (a hash rather than a couple of scalars).

2. Investigate how (?>foo) works. Can it be applied?

5. How can a tracked pattern be serialised? (Add freeze and thaw methods).

6. Store callbacks per tracked pattern.

7. Deal with [:punct:] character classes

8. foo(?:\.|-)bar is not character classed in indented patterns

12. utf-8... hmmmm...

13. Consider the following:

    $ eg/assemble -d2
    sing
    singing
    sting
    path 0 in [s {i=>[i n g {* i=>[i n g]}] t=>[t i n g]}]
     node 1 in {i=>[i n g {* i=>[i n g]}] t=>[t i n g]} opt=0
      | off=-1
      | path=(g:[n i t])
      | counts: reduce=1 fail=0
      | off=3
       node 3 in {i=>[i n g]} opt=1
       | fast fail {* i=>[i n g]}
      | +failed i
      | counts: reduce=1 fail=1
     : node scan complete opt=0 reduce={g=>[[g n i t]]} fail=[[i n g {* i=>[i n g]}]]
     | -simple opt=0 unrev [g n i t]
      _unrev path fast [g n i t] -> [t i n g]
     | +fail [i n g {* i=>[i n g]}]
     node 1 out fail={i=>[i n g {* i=>[i n g]}] t=>[t i n g]}
    | head=[] tail={i=>[i n g {* i=>[i n g]}] t=>[t i n g]}
    | unshift s
    path 0 out head=[] tail=[s {i=>[i n g {* i=>[i n g]}] t=>[t i n g]}]
    final head=[] tail=[s {i=>[i n g {* i=>[i n g]}] t=>[t i n g]}]
    final path=[s {i=>[i n g {* i=>[i n g]}] t=>[t i n g]}]
    /s(?:ing(?:ing)?|ting)/

    In other words, there is scope for a further approach to tail-sliding.

	Remember, there is more than one place in the code that deals with tail
	sliding. Why is it so?

14. Adding qr//'ed patterns. For example, consider
    $r->add ( qr/^abc/i )
		->add( qr/^abd/ )
		->add( qr/^ab e/x );
    this should admit abc abC aBc aBC abd abe as matches

15. Methods to specify adding ^, $, \b, \A, \Z to resulting pattern,
    and/or any arbitrary prefix/suffix

16. Allow a fast, unsafe tracking mode, that can be used if a(?bc)?
    can't happen. (Possibly carp if it does appear during traversal)?
