I purposely punted on inverted character classes because they brought up a major usability issue that I didn't have a quick solution for. The expression /[^abc]/ should match '@', ' ', and 'q', but, by the numbers, the majority of generated matches would look like '{angry unicode that you can't even see}'. This brings up the idea that you don't just want valid matches, but a meaningful set of examples that covers different ways of matching.

Likewise, I imagine it might be useful to specify some background language that matches should be taken from. That is, you might want to tell it to show you example matches made from snippets of valid html, from email-style English text, ascii-only strings, arbitrary unicode, etc. Incorporating this kind requires a lot of original thinking about usability (and some prototyping to figure out what would even make sense).

Since the intersection of two regular languages is a regular language, you could reduce generating 'background language' example matches to taking intersections. It's unfortunate how rare it is for libraries to provide you that operation.

(Same thing for HTML: intersecting a regular language with a context-free one is context-free.)

you support . which seems to pick random ascii characters