Issue: wiki bbcode stops parsing. Is there a way to find out why?

This has something to do with the following construction:
When you use this in a regular post, all BB-Codes that appear after it do not render properly:
If that is Waindigo's TABLE BB-Code, it uses its own internal plain-text flag, but does not actually render as plain-text (which can cause security vulnerabilities in VaultWiki). VaultWiki attempts to workaround this vulnerability.

The question is, does this happen for all BB-Codes using this construction, or only the TABLE BB-Code?

If it's only the TABLE BB-Code:

If it happens while VaultWiki is disabled, then it's a problem with that BB-Code, or it's a problem with how XenForo interprets the tag's plain-text flag when the tag itself is wrapped in PLAIN (without a closing tag, then a stacked plain-text flag would not go away).
If it resolves while VaultWiki is disabled, then it's a problem with the VaultWiki workaround.

There might not be a way to resolve this without breaking other things. You can avoid the problem by including a closing TABLE tag in your "example"

It is indeed waindigo table code.
I have closed the table tag but it does not solve the issue. So next I just removed the whole section. Then a few more sections were parsed but now it ends at the 'lists' section and from there no bbcode is parsed. No table bbcode is used in that section.

This occurs due to code intended to handle certain BB-Codes with problematic designs (such as the original Waindigo code). The workaround VaultWiki uses has issues with content that looks like opening tags but that don't have closing tags. In LISTs, this includes the list items * which don't have closing tags. So after 5 years of trying to support the quirks of those third-party BB-Codes, we must remove that support.

Since the original Waindigo code was taken up by another developer who claimed in 2017 to intend to fix the design issue, we are removing the workaround. If the developer never actually followed through, then perhaps this will get enough people complaining so that they do.

Also since the new developer has no intention of updating the BB-Code for XenForo 2, and XenForo 1 is no longer supported by XenForo, perhaps now is a good time for users to migrate away from that BB-Code anyway.

In our opinion, making sure that stock XenForo BB-Codes work as expected is more important than making sure a third-party's unsupported and flawed BB-Code is not conflicting.

Workaround removed in the next release.

This also occurs due to code intended to handle rendererState preservation codes in plain-text contexts, specifically for the case when parsed content is passed as an argument to a template that uses that argument inside a PLAIN tag or something similar. In that case, without special handling, the rendererState hashes would be visible in the output.

Since the code no longer needs to account for third-party BB-Code workarounds using similar logic, a slightly different approach can be used that does not affect all BB-Codes. Since the rendererState codes will always close, we do not have the problem of worrying about unclosed tags.