If I came across the code in the original post, I would be confused as to what the Or operator applied to. With a regexp, the parenthesis make this clear.

I would also assume that Exactly(1).Of(".") was meant to match a literal ".". In a PCRE, you can surround a section with \Q...\E to force literal interpretation, but I believe in .NET you would need to call Regexp.Escape.

The overall concept is not a terrible idea, but you should probably become a little more familiar with regexps before trying to write a library that creates them. While some things in the sample seem a natural product of being code generated (e.g. "@{1,1}" instead of simply "@"), the use of "(?:" in many places is simply not needed.

It seems a little misleading to write "Which one of these snippets would you like to encounter within your source code" and then go on to compare the generated regex code with the hand-written builder code. The generated regex is much uglier, more redundant, and more complex than what a person familiar with the syntax would write (e.g. grandparent's example regex).

Also, does the builder library support captures (i.e. pulling out substrings that match subpatterns)? That is a pretty important feature for a regex library.

Just wondering: why do you build a regex and not directly a finite state automaton? Sure, you can not have backreferences, but you can use Hopcroft minimization, etc.