MikeA

That's exactly how I would expect it to work.

By the way, for reference, I think the other discussion that Mike mentioned is this one:
 

Yes.
I guess the way I use a group is to control the paragraphs which will be very similar. Think of a newspaper, we have Stories, Headlines and Captions. The different sections, News, Sports, Finance, Entertainment, etc., would have different Styles and I would set up different Groups for them simply to keep the Sports formats away from the Finance formats. For a simple book (a work of fiction)  I would use Group Styles to make changes to the font family easier to manage, different font family means different number of pages which equals more or less paper costs. Using a different font for one article in a magazine means the story fits the space, or simply alters the colour of the page design. One Magazine with two dozen stories and the two dozen Groups may seem to be overkill but it is easier to manage.
What it comes down to for me is that I like it. I plan on using groups whenever I may need to make changes to font choice, leading, or even justification at a later date.
The only real and immediate advantage I have seen is that using Group styles means I cannot inadvertently apply a Group Style which could happen If I used Paragraph Style to base things on resulting in the 'wrong' style being applied. I do admit that it is quite a minor advantage.

The “Body text group” style has “No Break” (in Position & Transform) set to ON.
Setting it to OFF seems to fix the problem, but I can’t find anything about it in the Help.

Maybe upload Document A and B and maybe someone can work it out, this will also see if the documents behave differently on a different system.
 

I frequently have several styles, both Paragraph and Character, based on Base (group) and I will suddenly realize that I have the wrong typeface chosen. Now there would be no difference if Base (group) were in fact Base (paragraph) in that situation. But I find it at times easier to work with settings like font family for a whole set of settings in one group style.
I spend a fair amount of time thinking about what the various settings will be for paragraphs. Things I worry about are First Line Indents, Indents in general, Widows and Orphans, Flow options, Keep with next, Justification. Add in things like Drop Cap and Initial Words needing their own Character Styles (or not, your mileage may vary) and I just find having all the font settings being in one place more workable. Then I can change indents in the one style that needs that change and that change happens only in that style.
I will have a separate group style for Headings and do the same thing. At times I will use a group style for Callouts and/or Captions but generally don't.
To sum up, I have several Styles which will have very few settings made in them because the bulk of the work designing how the paragraph looks is done in the group style. Everything is inherited from the Group.

I can't speak for @garrettm30 but the way I work is to make a Group Style called Base and that Base style is based on [No Style]. Base defines Font Family, size, leading, indents, alignment, text colour, ligature use, and on and on. Everything I think the Basic Normal Bulk paragraph needs, then I make a Paragraph Style based on that and change nothing.

A search in this part of the forum didn't turn up the following requests regarding Styles, but beg pardon if they've already been discussed and I've just missed them.
The newbie experience: Select an object, select the make-a-style-from-it item from the object's context menu—but then it appears that nothing has happened. I thought I'd encountered a bug and tried it a second and third time. Still nothing. Then it occurred to me I'd better check Studio > Styles to see what might have changed there. Of course there were three new styles.
User error, yes, but the "nothing happened" experience is perplexing and could be improved. I would like to suggest: Immediately after saving a style, the user sees a small dialog in which the new style can be named. Then there's the question of its category—if there are already user-defined categories. If there are, their names would appear in a drop-down menu in the dialog where the style's name can be entered. If the user simply clicks the dialog's CLOSE button, the style is saved using the default name selected by Publisher, and the style appears within the default category. Frosting-On-Cake: a CANCEL button...clicking that one would cancel the save-new-style operation entirely.
Additionally: the ability to cut and paste (or copy and paste) styles between categories within the Styles panel. Of course, if there is a name conflict, error message: sorry, can't do it. But, Frosting-On-Cake: if a name conflict occurs, the user has the option to rename the style being moved or copied, or just cancel the operation.
 

Yeah, the [no change] setting is different in Affinity than InDesign (what I came from and still use to an extent), and it took me a while to get used to. I don't think it is bad, but it did require me to think about styles a little differently.
To me, the [no change] setting makes perfect sense in styles that are based on other styles. It would mean that when you apply the child style, each attribute set to [no change] is given the value inherited from the parent style.
The confusion for me involved [no change] settings in the style at the top of the hierarchy. InDesign still applied some change even there, some default format presumably coming from its [Basic Paragraph] style. I never messed with the [Basic Paragraph] style on the basis of recommendations such as the one here. But in Affinity apps, every attribute that is [no change] in the style definition is undefined, and when applied to text, that attribute is left unchanged. I think that could be powerful, but it helps to know that is what is happening.
My preference is to be in control of everything, so in Publisher I define a base style with basically everything explicitly defined, and I will tune that base style to the needs of the given document. Then all of my other styles are children or descendants of that base style. That way, "You know what they say when you assume things…" is not a problem when it comes to style definition.
Yep. I'm one of those. My thought is let the author do what he does best, and leave the format to the layout artist.

(This appears to be the feature-requests forum, but I've been wrong before. If I picked the wrong location please advise.)
I would surely appreciate improvements to the Edit Text Style dialog, which could be made easier on the end-user.
Dropdown menu for selecting styles
Please consider adding a drop-down menu to this dialog's first panel (the one named, simply, "Style"). Purpose: select some other style for editing. It would be useful having the option to filter the display: all styles, versus paragraph styles only, versus character styles only, versus only styles presently used in the document.
UI Font size   : -)
Text throughout Affinity Publisher's UI is small enough to make things, well, a bit hard on some of us. I'm glad I don't use a 4K monitor — if I did the UI would be so hard to read that I would probably not have purchased the program after using the trial version. Even on this laptop with its relatively small monitor, there is plenty of "screen real estate" to expand a dialog like Edit Text Style if a larger UI font were used.
I've noticed that Publisher's Mac version has a way via Preferences to adjust the fonts in the UI. Not so the Windows version. So Windows version users are stuck with the small UI fonts, as-is. (I do already have fonts somewhat enlarged via Windows' own control panel. But enlarging them further using that control will not likely give good results.)
Display of specific style information
Describing all kinds of data—font, size, color (etc.)—simply as "No change" says nothing about the actual style data. This is unlike the style information displays in word processors or page composition programs I've used in the past. Even in the first ("Style") panel of the dialog, the summary information at the bottom of the dialog (in the "Style Settings" field) includes the actual typeface name only if you are editing "Base." In short: Understanding fully what's in a style has been made unnecessarily difficult. Please consider ways of improving this.
Copying style data to the clipboard
I'd hoped I could copy the information from the dialog's "Style Settings" field to the clipboard so that I could examine the style information using a more readable typeface, in a text editor or word processor. Each item in the field ends with a semicolon. So, I figured I could replace each semicolon with "newline"—voilà, more readable text.
But the information within this field cannot be selected or highlighted (let alone copied). Please either add a "Copy" [to clipboard] button for the field, or at least make the text in it selectable with the mouse (or all of it selected at once by clicking in the field and pressing Control+A) so that the user himself can copy it to the clipboard and paste it somewhere else.
Thanks.
 

I just tried this and it works as expected. I did:
Assign all paragraphs a newly created paragraph style that only changes the font. Assign a couple of words in the middle of a paragraph a new character style that changes the colour and sets a different font family > font colour and font family look different than the whole text. Go back in the character style (Edit character style) and set font to 'No change' > the font immediately looks the same as the whole text but the colour is different (because I did not change that). What might be different with your setup?
d.

@Lagarto
It does seem like a mess.
That you know of, is there a way to originate a style of either sort in Publisher that is truly based on "no style" (neither paragraph nor character style)?
I agree about find/replace. The way I've worked around this problem, in tests, is to place two or three "found" text items near one another so that I can see what happens later when I click "Replace All". This of course requires time to set up and test. The program needs both "Replace once" and "Replace and Find Next."
As much as I hate this idea, I am wondering if local formatting within body text should simply be done with "hard" formatting—not out of sloppiness but for, well, survival's sake. (It's ghastly, I know.) Then when need be, "hard" formatting can be easily removed and replaced. If it is fixed with a character style, a replacement done incorrectly might not replace the local formatting at all. (example below)
Publisher doesn't support import of HTML files, so creating character and paragraph styles "on the fly" while importing HTML is out of the question. I was disappointed on finding this; for some reason I had expected it. What a simple matter it could be with simple CSS definitions for both kinds of styles.
«
Another way to resolve the problem is creating character styles for local formatting (like italics, bold and bold italic). This way it is not lost simply because another paragraph style is applied to text.
»
I have found that when I did not set up the character styles correctly, applying a new or edited paragraph style to a paragraph did not change the character formatting applied with the character style. In a test I had a paragraph styled using Arial "roman" for body text and Arial Bold for emphasis—the boldface was a character style. I edited the paragraph style and changed its font to EB Garamond and used a different point size—and all of the Arial Bold remained as-is (both typeface and size) due to the character style. Totally undesirable. Clearly this was my error in setting up the character style. Ok—then what would have been the right way to do it? Possibly defining the character style as based on "[No change]" for both its typeface and size? I have to test this...

The text + character + base styles interactions might be complex because end-users asked for the complexity. My impression, having worked with other publishing systems in the past, is that they are unnecessarily complex. For example, I wasn't prepared for finding that a previously defined paragraph style seems to be completely removed and stripped down to bedrock, so to speak, if its underlying character style is changed to "no style"—as if the previously defined paragraph style had no meaning after all. My reaction was: "What the hell just happened..." How to make sense out of it all? I got a bit of a chill thinking that in making a long document, a few bad decisions at the outset, style-wise, could result in a later cascade of errors requiring hours to fix.
The "No change" selections in the style-editing dialog were also eye-openers and I'm trying to grasp what they mean. In one case it looks to me as if selecting "No change" in defining a character style is the equivalent of "base this style, first of all, on the underlying paragraph format"—as can be done in MS-Word. Or in CSS, in which you can have a local formatting attribute that isn't wedded to any specific HTML element.
There might be ways to simplify the paragraph+character+base style setups and make simple predictable routines. I don't know what the simplifications might be, yet. (The un-MS-Word-like behavior of styles in my Word "clone" word-processing program complicate this all the more, but that's another story.)
I read through a "What are group styles?" thread here and knew little more at the end than I'd known at the start. People were trying to get across that "group style" doesn't mean "based on," but just what it means, I dunno yet.

(...)

(This appears to be the feature-requests forum, but I've been wrong before. If I picked the wrong location please advise.)
I would surely appreciate improvements to the Edit Text Style dialog, which could be made easier on the end-user.
Dropdown menu for selecting styles
Please consider adding a drop-down menu to this dialog's first panel (the one named, simply, "Style"). Purpose: select some other style for editing. It would be useful having the option to filter the display: all styles, versus paragraph styles only, versus character styles only, versus only styles presently used in the document.
UI Font size   : -)
Text throughout Affinity Publisher's UI is small enough to make things, well, a bit hard on some of us. I'm glad I don't use a 4K monitor — if I did the UI would be so hard to read that I would probably not have purchased the program after using the trial version. Even on this laptop with its relatively small monitor, there is plenty of "screen real estate" to expand a dialog like Edit Text Style if a larger UI font were used.
I've noticed that Publisher's Mac version has a way via Preferences to adjust the fonts in the UI. Not so the Windows version. So Windows version users are stuck with the small UI fonts, as-is. (I do already have fonts somewhat enlarged via Windows' own control panel. But enlarging them further using that control will not likely give good results.)
Display of specific style information
Describing all kinds of data—font, size, color (etc.)—simply as "No change" says nothing about the actual style data. This is unlike the style information displays in word processors or page composition programs I've used in the past. Even in the first ("Style") panel of the dialog, the summary information at the bottom of the dialog (in the "Style Settings" field) includes the actual typeface name only if you are editing "Base." In short: Understanding fully what's in a style has been made unnecessarily difficult. Please consider ways of improving this.
Copying style data to the clipboard
I'd hoped I could copy the information from the dialog's "Style Settings" field to the clipboard so that I could examine the style information using a more readable typeface, in a text editor or word processor. Each item in the field ends with a semicolon. So, I figured I could replace each semicolon with "newline"—voilà, more readable text.
But the information within this field cannot be selected or highlighted (let alone copied). Please either add a "Copy" [to clipboard] button for the field, or at least make the text in it selectable with the mouse (or all of it selected at once by clicking in the field and pressing Control+A) so that the user himself can copy it to the clipboard and paste it somewhere else.
Thanks.
 

Does this video help? The Reset Formatting button isn’t easy to spot stuck out there on the right.
2020-04-01_13-32-26.mp4

(...)

(...)

(...)

(...)
 

(...)

(...)

In Publisher you have the Fields studio panel, where you can change the document title.

(...)

(...)