Wosven

I agree with Wosven: being able to apply paragraph styles to individual characters is confusing.
Paragraph styles for paragraphs. (Whole paragraphs.)
Character styles for characters. 
It is confusing to be able to apply more than one paragraph style to a paragraph, especially as the order in which they are applied determines which elements of the style appear. 
For instance, try setting a paragraph to Body style, select all, then 'Apply "Line Below" to Characters'. Now try it in reverse.
If Body style is applied first, there is no line below.
If Line Below style is applied first, the line below appears.
And with multiple paragraph styles applied, there is no quick way to clear overrides (or even find where they are). Selecting the whole paragraph then clicking on another style sometimes leaves one of the original paragraph styles selected.
Also, there is a bug (?) where if a new text box is drawn with a style already selected, changing the style adds the style to the original one instead of replacing it. The only way out of this is to select 'Detach Characters from "Stylename"' from the flyout menu. (But, these bugs are inconsistent and depend on which styles have been applied before.)
I realise there are still bugs to remove, so it's hard to work out for sure how styles will eventually work, but I think being able to apply multiple paragraph styles is a mistake. The whole idea of one style being 'based on' another is surely a better way (and already implemented), and then keep character and paragraph styles separate.

It is intended as a quick way of switching between linked text styles. It is used by Text > List > Increase Level and by pressing tab at the start of a paragraph. Increase level takes the paragraph's current style, find its Next level style, and applies that to the paragraph. (If one isn't set, then it increases indent instead.)
The linked styles can do anything you want. The default text styles use them for three things:
Tab at the start of a Bullet 1 paragraph will turn it into a Bullet 2 paragraph. This changes the indent and also the bullet symbol. Similarly Bullet 2 => Bullet 3. Tab at the start of a Numbered 1 paragraph will turn it into a Numbered 2 paragraph. This is a convenient way to get multi-level numbered lists. Similarly Numbered 2 => Numbered 3. Tab at the start of a Header 1 paragraph will turn it into a Header 2 paragraph. Shift-tab does the opposite to tab. For example going from Bullet 3 to Bullet 2.

I agree for groups, not tags. It would be another step (adding them/modifying them/getting them updated) that would take longer than dragging/creating in a floder. And where/how to display them? A larger studio or style's names + tags on 2 lines?  
"Based on" and "Groups" should be dissociated, since the hierarchical view is only usefull when creating/modifying styles. It's for conceptual work (at the begining, and when doing a lifting to a document).
People working day to day with those styles need Groups when styles are used on specific parts (clicking in the text, highlighting a style of this part will show/open the group folder containing all the styles for this part.
Having the character styles in the same studio can be a problem too if they end up at the bottom while your paragraph styles are in the upper part.
Ususually you don't need to have dupplicates of character styles: bold/italic/bold italic work for most of the paragraph styles, and some are specific depending of parts of the document or depending of type.
Some can be hidden in folders when used inline (bullets, drop caps, initial words), and other can be listed to be easy to choose.
If you assign shortcuts to styles so people working on a lot of different documents could easily visualize them, you should be able to look at paragraph and character styles at the same time if checking shortcut is needed (avoiding scrolling in a list).

Thanks to Serif I officially pulled the plug on Adobe. 

Indeed, text frames can have specific baseline grids now. But my remarks remain: it makes no sense to have a toggle to turn the document baseline grid on or off. It is still overly complicated and makes no sense at all.
It seems that display/hide for a baseline grid of a text frame is not possible, by the way.
So indeed, let's ask Affinity to remove the baseline grid toggle and move the baseline manager to the document setup...
About snapping to the baseline grid, that works fine in Publisher: if you turn the option on in the snapping options, any object drawn on the page will snap to the baseline grid. Of course if you turn the baseline grid option for the whole document off, it won't work anymore. It is perfectly logical, but it doesn't make sense from a user perspective. That's exactly why the baseline grid toggle should not be there. In a way it make sense to never be able to turn the baseline grid of your document on or off. If you don't want to use it, don't activate it on paragraphs, styles, snapping or text frames...
Cheers,
Wim

Pure Vector, no pixels, some coffees
https://b-bertuleit.de/butterfly-vector-portrait/

Nice idea. I'd rather go for centered text. (And thanks for inspiring me with those pics).

Oland.afpub

@276ccm ,
I see what you mean, perhaps "Ö & land" is too heavy… but the 3 pics are strong an colorfull, we need to be reminded to read the text after switching from one to another

Nice idea. I'd rather go for centered text. (And thanks for inspiring me with those pics).

Oland.afpub

Nice idea. I'd rather go for centered text. (And thanks for inspiring me with those pics).

Oland.afpub

No worries! I think a no-wrap attribute would be nice, especially in these situations.
BTW, is this file slow on your system? It is extremely slow here and I don't know why. I've created similar and more complex pages here. But that file here is really slow.

Good point about the font. I tested with a heavier one, and it does increase legibility.
The white text is not ideal, but it'll have to do.

Öland 2018 Poster v03 Tre Konstnärer.pdf

This is a huge argument in favor of simplifying the entire approach. I can imagine to wrap my head around the current style system and develop a sufficiently logical and straightforward approach for my own documents. But (and this is indeed more than worthwhile to consider) when you have to edit other people’s documents and the options provided by the application are overly flexible, it will create a host of work to even understand what these people were thinking (or not thinking) when creating their documents. It will be a nightmare to debug documents created by people who didn’t take the time to understand the details of the current text style system.
Apart from the UI-related issues and the bugs I mentioned above, I see the biggest practical problems 
in blurring the border between character and paragraph styles without a UI solution that allows me to understand at first glance which styles are applied to which parts of my text and how I can disentangle and remove such style applications, in muddling together paragraph and character styles in a single, badly structured panel (just have a look at the hierarchical view: the very marked pattern of dark and light background rows that runs across the hierarchical system kills all visual dependencies that would be essential for perceiving a hierarchy; the indentation doesn’t help a lot; hierarchies need a different background color system than lists; a UI solution that forces me to squint and search is a bad solution), and in the lack of folders for organising styles (style groups are an interesting concept, but they cannot really replace a folder system). Hmm … I really hope this most important aspect of a layout application will be reconsidered … 
 
  

For this, try with another style with different color and for example bolder.
You select or click in a word, right-click on another para’ style and use : "Apply xxx to characters". Try applying different para’ styles after this…
Here a fast test (checking it's the same in .128 version)
paraCharStyles.afpub

+1 for @A_B_C
It's confusing. In the long run, it's easier to keep simple options, they'll be easy to rememberand use.
I've got an example with one of my ID script: I thought of at least 7 ways to use "Apply Object/Paragraph styles" depending of selection. In the long run I  only use 3 of them, and use other means of 1-2 more clicks to get the same result as the options I don't use.
If options are easy to understand and memorize, they'll be used.
Another problem is to be able to apply paragraph style to a part of text in  a paragraph, resulting in 2 or more paragraph styles applied to a paragraph.
This should be done only with character styles, or we'll spend time debugging/correcting documents made by people who won't understand this or that'll work fast without respecting styles and layout (this happens a lot in ID with people only using the pipette for “applying” styles).
DTP tools are complex and there's a lot to learn to get beautifull result. That's why I think the tools should help, permitting complex results with clear and well defined options.
I don't know how it is for others, but today documents and DTP apps are used by more than the one that layout pages for different reasons — he/she'll have to check/correct the file at some point before doing the PDF for print — and the easier the app is, the easier it is to explain how to do simple things in a document and avoid mistakes.
For example, paragraph styles behaving like character style give me headaches beforehand
 

my quick concepts

Shift-click, actually, but it could have been worse!

If to select several paragraphs with paragraph style applied to them  and there is no word with local formatting in the beginning of the very first selected paragraph but all  the words with local formatting  are just inside paragraphs, the “Reset Formatting” button is grayed out and there is no “legal” way to remove text local overrides.
The way around: you have to intentionally make the very first word of the very first paragraph something like bold or italic then after this the “Reset Formatting” button is active.

By default the number keys set opacity - which is fine. BUT AD doesn't distinguish between the standard numbers and the numeric keypad, to which I'd really like to assign a bunch of other shortcuts.
 
With 15 keys on the numpad, and at least 3 different modifiers, there are >45 keyboard shortcuts going to waste here!
 
Also, under the current system, if I do set a numeric keypad numeral as a shortcut, it doesn't warn me that there is an existing clash with the opacity function... worst of both worlds!
 
Thanks for your consideration.

Okay, so I had a look at the entire styles logic a second time. To be honest, I believe this approach is still not as straightforward as it could be. In my opinion, one of the main problems that still has to be solved is the use of tick marks. What you are doing with these tick marks is not only inconsistent with the Human Interface Guidelines for macOS, but also with your own use of tick marks in other places of Affinity Publisher. Let me explain.
According to the Human Interface Guidelines for macOS, a menu item that has a tick mark next to it is called a “toggled menu item.” Selecting such a menu item will toggle an option, that means, it will switch between two states (an “on” and an “off” state) when chosen, and Affinity Publisher uses such toggled menu items in many places. For instance, when I select a string of letters in a text frame and choose Text > Character Traits > Italic, my action will have two effects:
the italic style of the present font will be applied to the selected letters and secondly, the menu item Text > Character Traits > Italic will receive a tick mark. Now you are basically right in saying that this tick mark has an indicative function that is tied to a certain selection of letters. Whenever I select italicised text, the tick mark will appear next to the menu item Text > Character Traits > Italic. Whenever I select non-italicised text, the tick mark will disappear from the menu item Text > Character Traits > Italic. So far, so good.
But there is a huge difference between the mentioned menu item and the menu items that belong to the hamburger menus of the text styles. These are not toggled menu items in the previously discussed sense. They might be indicative for the properties of a certain selection of letters, but I cannot toggle the application of these properties by repeatedly selecting the same menu item. Rather, I have to use an entirely different menu to remove the property and the respective tick mark. This is not only against the Human Interface Guidelines for macOS, but also against your use of menus tick marks in other places, as discussed above.
I hope my description will make the issue sufficiently clear. What looks like a toggled menu item is actually not a toggled menu item. I predict this will create great confusion among users as soon as they really start to work with the text styles system. I hope you will be able to change this before you release the app to the public.
Alex 
 
https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/

OK, understood.
But it still doesn't really explain the purpose of Group Styles.
They are a poor way to organise because it necessitates selecting the Group Style in the Based on setting, thereby meaning you can't actually base the style on on something else; and I can't see why having a Group Style not being able to be applied is actually a feature? How is that better than just a normal style?
For example, if I go back to my example previously:
Main styles:
Heading 1 Heading 2 Body Bullet list Number list Appendix styles
Heading 1 Heading 2 Body Bullet list Number list To set up the above, you would have two Styles or Group Styles called 'Main' and 'Appendix' and then set the individual styles as Based on the Styles or Group Styles.
However, you might want the appendix body style to be based on the main body style and the Appendix Bullet list to be based on the Main Bullet list. With the Group Styles system (feature?!) I can't see how that would be possible because doing so would move the Appendix Bullet list to be 'under' the Main Bullet list in the hierarchical view.
Essentially, folders or tags would be hugely more flexible and useful. Personally, I would ditch Group Styles and replace with something useful and more flexible.

I’m sorry but I don’t buy the ‘more options are better’ argument  it is just bad design to have two features that essentially do the same thing.
Doing so makes it confusing because the app is more cluttered. It also makes it more difficult for different people to pick up working on a document that another person has worked on.
It’s all very well being in your own bubble but it is essential that it is as easy as possible for someone to open a document and immediately get to work on the the file. If there are different ways of achieving essentially the same thing, it is going to make it challenging.
I don’t mind which it is, and unless someone can provide a compelling use case for having them both, we should have either ‘based on ‘ or ‘group styles’.
Folders on the other hand would be very handy. Perhaps even better would be tags so that you could sort / search them as required on the fly. 

Thank you!...I was hoping to be able to reuse some of the objects in another drawing....but at least they will make some useful assets...

But there are a whole BIG BUNCH of us who very much want to be able to edit a pdf.   We are extremely grateful for this wonderful feature in Publisher.   Why don’t you just print your pdf’s straight from Preview (if you are on a Mac) and then close the documents?   But please don’t ask the Affinities to take away this wonderful option from the rest of us!

I often use Affinity Photo in combination with other software, like Daz Studio and Dynamic Auto-Painter.
Arachnophobia I was fairly easy to do. I shot the background at the Primus Vicus medieval village outside Halmstad, in Sweden. Then I rendered the spider and the viking shieldmaiden in Daz Studio, and composited using Affinity Photo.
Arachnophobia II was done in a similar manner. The main difference is that I had help from two live models, Petra Brewitz and Peter Markusson. The castle in the background of the final image is Borgholm castle on Öland.
I hope you enjoy the pictures.