Glad to hear completions work for you now, but you don’t actually have to to do the former to have the latter. This is because what scopes you define in your syntax XML and what scopes you address in your completions XML to insert completions for the former do not need to be linked. I’m going to try to illustrate how that is using your original case, the <perch:«.+» tags, as I am familiar with them already. Please bear with me.
Keep in mind you have HTML syntax scoping in Perch files through your inclusion of the HTML syntax. Assuming your Perch tags are defined as they were, i.e. as starting with <perch:«.+», when will that scope be active in Nova? Answer: only when <perch:«word» is actually present in the code. If only a substring of that is in the document (like <, or <p, or pe … you get the idea), it will not be scoped as a Perch tag (that is why your original completions did not trigger). Instead, the HTML syntax kicks in and scopes that substring as a generic opening tag, until it is specific enough for the Perch tag scope to apply instead:
<!-- “|” indicates cursor while inserting a tag -->
<per|> <!-- = generic HTML tag -->
<perch:«any char»|> <!-- = Perch tag -->
Now, when it comes to completions, this means that you cannot meaningfully offer perch:«word» completions scoped to Perch tags, because that scope only exists at a point where most, if not all, of what you want to offer as a completion has already been typed. This is the point where this discussion started.
The solution, obviously, is to offer Perch tag completions in the HTML tag scope. This has the advantage that completions kick in at a useful point, i.e right after the user starts typing a tag. However, as long as there are separate Perch tag scopes, completions will stop working as soon as Perch syntax highlighting kicks in, as that changes the syntax scope, as illustrated above.
To remedy this, you have three options:
-
Saying “bugger this for a lark” and just remove your Perch scope – what you did on your last iteration. This gets rid of the issue I just described, i.e. Perch syntax scoping kicking in and preventing completions. However, that might not be the best way to go. If Perch tags need to do anything differently from generic HTML tags (maybe there are specialised attributes? Unique contents, like nested tags? I don’t know enough about Perch to say), you have lost the opportunity to define that in your syntax.
-
Addressing both scopes. A <selector> expression in a completion can address several different scopes, using CSS selector syntax. For instance
<selector>
html.tag.open.paired, perch.tag.open.single, perch.tag.open.paired
</selector>
would mean Perch tag name completions are shown in all three scopes. You keep the ability to define Perch specific scopes and you get completions for them, whether the tag is recognisably a Perch one or not.
-
A variant of this is to define several different completion providers with different scopes. This is pointless duplication if they offer the same completions, but may be useful if the completions need to differ somehow in the different scopes. This will work just fine because Nova offers the completions of all providers whose scope selector and anchoring apply at the insertion point.
Just to drive the point home, because I think it is the main source of confusion: what <selector> does is to switch a completion provider on when the cursor is inside the selected syntax scope – no more, no less. There need not be any syntactic relationship between the completions themselves and the scopes they activate in. If you want to offer 
emojis as a completion for XML tag names, you do not need to define a syntax this is acceptable in first; a completion provider scoped to the right selector will be enough.
For your Perch syntax that means, conversely, that you don’t need to avoid defining Perch specific syntax scopes just to get completion working: HTML and Perch scopes can cohabit nicely,
