I cannot seem to draw a right curly brace in a way that it recognizes it. It's almost as if the recognition was rotation-invariant because I sometimes get v or check as a false positive for }.
I can draw a } that it will recognize, but it takes special effort. A natural } that no human would have difficulty with tends to be "recognized" as a ] instead. Even when there is a VERY prominent center point protruding from the shape.
I also have trouble with the registered "arrow" shape - if you overshoot the point when you're doing the return from the top half of the arrowhead, you'll get recognized as a random non-arrow shape.
The "x" does not match the way I would naturally write an x, and it really highlights the fact that many common shapes are not drawn in a single stroke. (Also a problem for the arrow, as well as the "delete", which is clearly supposed to be visually identical to "x". It will be a problem for a large number of important characters that don't exist in the demo, such as A, t, and +.)
Between that and the fact that it has so much trouble recognizing }, which is visually distinctive and is naturally drawn in a single stroke, this doesn't seem like an algorithm you'd want to let users interact with.
Adding a single example of a } as drawn by me more or less removed that recognition problem. It introduced a symmetric problem where obviously squared-off ] was recognized as }. Adding the perfectly squared ] as an example of "right square bracket" reintroduced the inability to recognize very obvious }. I suspect this is not a solvable problem without switching to a more effective algorithm.
The whole family of algorithms (including the multistroke variants) suffer from this issue. They are very clever, and maybe suitable if your set of templates are sufficiently distinct, but they don't deal at all well with similar shapes
