rcheetah

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 
correct

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 
correct

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 
For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 
This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 
correct

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 
correct

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

This is definitely not one of the most important features, but as a GREP-engine is already implemented: may we hope for something like GREP-Styles?
This is a feature I don’t use on a daily basis, but it is something I’m very very glad to have from time to time.

OK, I misunderstood what you want. You're trying to get only the lines with chord letters, not the paired lines that my suggestion gives.
With a bit more experimenting I have found something else that I think is a bug, which I will report separately. But this selects just the chord lines:
(?-s)^.* {4,}.*$ The (?-s) at the beginning prevents "." from matching the end of line/paragraph. And setting that option also seems to remove the need to make the ".*" non-greedy.

First, $ is matching the end of a paragraph. The entire problem with your (and my) earlier attempts was that . matches an end-of-paragraph, too.
So, in the expression (made non-greedy)
^.*? {4,}.*?$ you were expecting:
^ to match the beginning of a line or paragraph (and it does). .*? to match some unspecified characters (and it does).  {4,} (that is, a space followed by {4,} to match 4 or more spaces. .*? to match more unspecified characters. and finally, $ to match the end of a line or paragraph (and it does). The problem comes in at step 2. Consider the first 2 lines of your text (corrected to make sure there are 4 spaces in the second line):
Intro G C There's a paragraph break at the end of each of those, so in regex terms it could be thought of as looking like this:
Intro$ G C$ You were expecting that the regex would not match the first line at all, as it has no spaces in it.
In fact, though, at step 2 the .*? matched "Intro$G" because the . can match anything, even the end-of-line or paragraph break. Then at step 3 the 4 or more spaces matched the "    C". At step 4 the .*? matches the empty string, and finally at step 5 the $ matches the $
Thus, the issue is really the fact that . can match the end-of-line, which allowed the expression to match from the beginning of line 1, rather than from the beginning of line 2.
The fix was to insert (?-s) at the beginning. You can find an explanation for (?....) in several places. (?-s) is simply one of the variants of that general form:
I used my Python reference material, as Python's regular expressions are reasonably close to ECMAScript/Perl regular expressions. But also, for ECMAScript (though it doesn't cover this case). And for Perl (especially the section on Modifiers). Basically, the (? signals the start of a modifier. The - negates the modifier (turns off a switch) and the s is the switch that is turned off. The s switch tells the regex processor whether . should match the end-of-line (or end-of-paragraph, in Publisher). When processing regular expressions Publisher sets the flag on, allowing . to match end-of-line and end-of-paragraph, so if you don't want it to you have to turn that flag off.