The thing to watch out for, is that formally, a parser is just something which can recognise a grammar with particular properties. A PEG (Parsing Expression Grammar) is simply a language grammar which can be written as a combination of the operators on the Wikipedia page. Any practical Context-Free Grammar will likely be also expressible as a PEG (though this is technically an open academic question).
The key thing to remember is that for the parser to be “complete”, it just needs to be able to take in a grammar (i.e. the definition the user writes for the parser) and the input, and either say “yes, this input follows the grammar” or “no, this input does not follow the grammar”. Hence, my statement was “now NimbleParsec can recognise any PEG grammar”, which of course is a prerequisite for “NimbleParsec can use a PEG grammar to turn binary input into some useful datastrucure”, which @OvermindDL1 is referring to. Unfortunately, this problem is far less interesting to researchers, and so “what features are missing” is probably better answered by reference to other popular PEG-style parsers rather than a paper or reference page 
This is indeed how I was planning to handle XML tag closing/opening. I can see that right now @OvermindDL1 is writing an answer, but my guess is that the answer will again involve the fact that these are not really composable with the rest of the parsing definitions, but rather require a specific external function to be called (if they were composable, you could make a version of every single base combinator which also depends on or modifies some state). There’s also the local/global state thing which ExSpirit has, (I actually have no idea how that works or why it is useful though).
