Some comments:

• I would put the Levels subpanel first, it is the most important info and widget of the modifier. Now that we have everything organized in subpanels I would even consider adding extra buttons to this panel (level up, level down, highest level, lowest level) just for convenience, as that will make the interaction easier than manipulating the value directly
• Unsubdivide should not be in the Remove subpanel. It does not remove levels, it adds another one, just like subdivide, but in the opposite direction.
• We still need to decide what we do with the Catmull-clark/Simple property. If we can't remove it for 2.90 it should probably go in the advanced subpanel as it is something you usually don't want to modify

There are also some features that are still not merged in master.implemented that require additional buttons, but I don't think it would be a problem adding them to this layout

• D7644 Adds a "Refit" button than could go in the Shape subpanel. If we add the Automatic Apply Base checkbox in 2.90 that could also go there
• I was planning to add an info label to the modifier to show how many vertices the next subdivision is going to have (this is not as intuitive to calculate as it seems), Something like that can also go in the Subdivide subpanel

In D8187#199068, @Pablo Dobarro (pablodp606) wrote:

• We still need to decide what we do with the Catmull-clark/Simple property. If we can't remove it for 2.90 it should probably go in the advanced subpanel as it is something you usually don't want to modify

Removing it would be great. I started doing some versioning for that, but I wasn't sure whether to just remove it from the UI and set it to catmull-clark or to remove it entirely.

There are also some features that are still not merged in master.implemented that require additional buttons, but I don't think it would be a problem adding them to this layout

Great, yeah, the subpanels make it much simpler to properly add new buttons.

• I was planning to add an info label to the modifier to show how many vertices the next subdivision is going to have (this is not as intuitive to calculate as it seems)

That would be helpful. Although if it's not a simple calculation I wonder if its result could be cached somewhere so it wasn't recalculated every redraw.

Also, P1502 should get you something like this:

I would put the Levels subpanel first, it is the most important info and widget of the modifier.

Also, I'm not sure it's necessary to put levels on the top, even if it's the most used. As long as it's visible and open by default, the order doesn't have to correspond to the importance. But I don't have a strong opinion there.

In D8187#199107, @Hans Goudey (HooglyBoogly) wrote:

I would put the Levels subpanel first, it is the most important info and widget of the modifier.

Also, I'm not sure it's necessary to put levels on the top, even if it's the most used.

That is not a question of importance. That should be always displayed, outside of a sub-panel.
An animator, that is not the sculptor, may play with those settings like he does with levels of a Subdivision Surface modifier.

There is no use for 2 sub-panels to subdivide and remove. User will need to be able to do both operations during same session.
That could be a unique sub-panel called Add & Remove.

In D8187#199112, @ronan ducluzeau (zeauro) wrote:

In D8187#199107, @Hans Goudey (HooglyBoogly) wrote:

I would put the Levels subpanel first, it is the most important info and widget of the modifier.

Also, I'm not sure it's necessary to put levels on the top, even if it's the most used.

That is not a question of importance. That should be always displayed, outside of a sub-panel.
An animator, that is not the sculptor, may play with those settings like he does with levels of a Subdivision Surface modifier.

There is no use for 2 sub-panels to subdivide and remove. User will need to be able to do both operations during same session.
That could be a unique sub-panel called Add & Remove.

That's a good point. If it's at the top anyway and doesn't need a label, it doesn't have to be in a subpanel.

Maybe that single panel you mentioned could be called "Subdivisions". "Add & Remove" seems a bit general.

To avoid confusion, maybe "Rebuild Subdivisions" button could be renamed "Rebuild Levels".
But I am not sure, if that is not replacing a potential confusion to another one.

Am i the only one concerned about "Delete higher" dont matching the right column and being a little larger?

In D8187#199177, @David (Galagax) wrote:

Am i the only one concerned about "Delete higher" dont matching the right column and being a little larger?

That should be fine with another button on the left. ("Delete Lower" when it's added)

In D8187#199112, @ronan ducluzeau (zeauro) wrote:

There is no use for 2 sub-panels to subdivide and remove. User will need to be able to do both operations during same session.

I thought the same thing when I first saw it, and Subdivisions sounds like a good name for the new combined panel.

In D8187#203134, @Julian Eisel (Severin) wrote:

I feel like this is taking sub-panel usage a bit too far.

Honestly I agree. It's interesting as a concept but yes.

• It seems to me that most content of the Levels, Subdivide and Remove panels are typically used together, and should be at the top without a subpanel. Or at least these options shouldn't be in 3 separate ones.

Right, we agreed on that further up in the comments, I didn't get around to updating the patch though. Will do.

• Within the merged panels, we could still use labels to group settings.

The problem with labels is they look very out of place with the new layouts, since they are the only button that's aligned to the left.

• Catmull-Clark/Simple could indeed go into the Advanced sub-panel. Would prefer if this was just a checkbox, but I guess that doesn't work since it actually re-calculates the entire multires geometry.

I tried to look into getting rid of this button, workflow-wise it's completely useless, and Sergey suggested it was possible in an earlier comment.

• Some changes we do here should probably also be done to the Subdivision modifier (Catmull-Clark/Simple switch).

That toggle is already like that in master. Are there any others?

In D8187#199103, @Hans Goudey (HooglyBoogly) wrote:

Also, P1502 should get you something like this:

I can't get it to expand to the full row with centered buttons though.

Not a fan of this, it does look quite a lot like playback buttons. If we have such helpers, they can just go into a menu. Just like the modifier header menu.

It works much better with unaligned buttons, and those icons definitely aren't great there. Ideally we would have more general "First", "Previous", "Next", and "Last" icons.
With D8194 I guess a menu is better than nothing, but it would makes them pretty redundant, the idea is that they're easier to press than the little arrows on the number button while sculpting with a tablet.

Catmull-Clark/Simple could indeed go into the Advanced sub-panel.

Actually, I'm sort of concerned with this because it hides the relationship between the "Subdivide" button and the subdivision type toggle.

By the way, this was more what Pablo and I were envisioning for the switch buttons:

I think this is fine now.

Having the Catmull-Clark/Simple separated in the Advanced panel doesn't seem to be an issue to me. The other options there have this relationship as well. I think it's clear from context that this relates to the subdivision (which is what this modifier modifies). We could rename it to Advanced Options though and make it the first sub-panel.

Also (maybe a question for @Pablo Dobarro (pablodp606)) how often is the Optimal Display option used, maybe that should be in Advanced too?

In D8187#203265, @Hans Goudey (HooglyBoogly) wrote:

By the way, this was more what Pablo and I were envisioning for the switch buttons:

Eek, still don't like this at all! :) I think a menu is fine, the buttons would be only marginally faster.

In D8187#203294, @Julian Eisel (Severin) wrote:

Eek, still don't like this at all! :) I think a menu is fine, the buttons would be only marginally faster.

That depends on how many times they're used in a session. I don't do much multi-res sculpting, but I do use a tablet, and nice, big, easy-to-hit buttons like this would be much faster for frequent use than items in a menu, or the small arrows on the fields.
Since the level can be increased/decreased on the fields already, I don't think having those in a menu would really help (it would be slightly easier to hit, but would take two clicks to access).
Since you don't like them at the top, maybe having them in a subpanel would work? Or add an option to display the tablet buttons in the already present modifier menu?
That way they can be hidden by default, but tablet users can turn them on.

Honestly, I think @Hans Goudey (HooglyBoogly) & @Pablo Dobarro (pablodp606)'s design fits in pretty well. :)

@Julian Eisel (Severin) To me the layout looks good. I think the arrows at the top would be a great addition.
So having these big buttons with arrows in addition to D8194 is a nice indicator that users can switch between levels in a fast way.
I will personally rely on shortcuts most of the time to subdivide and switch between levels in sculpt mode and so will most people once they get to know the shortcuts. Because of that it's nice to be able to close most panels so that only the levels and arrow buttons are shown.
I think the arrow buttons should not be put into a menu so that they are easily accessible since people will press them often.
But hovering over the buttons will then also hopefully reveal the shortcuts to most people at some point.

@Pablo Dobarro (pablodp606)
I wonder if the buttons are only meant to switch the sculpt levels though? Or would they change the viewport levels as well when outside of sculpt mode?
IMO they are most useful for the sculpt levels so maybe they can be paired more obviously in the layout too?

I think this can be committed now.
The level operator buttons are a new feature, independent of the 2.90 layout changes. I suggest to open a new design task for this and D8191. They can go into 2.91 then.

In D8187#203294, @Julian Eisel (Severin) wrote:

Eek, still don't like this at all! :) I think a menu is fine, the buttons would be only marginally faster.

I think the margin is large enough, and that using arrows in the icons is fine too, but they should be oriented pointing up/down indicating higher/lower. Just my 2 cents worth.

Some Initial feedback on the UI

Use Level as a separate title label at the top or add it to all the options like:

Viewport Level
Sculpt Level
Render level

Having only Level Viewport and the rest without the level word makes it seem like they are all different types of functionalities, but in fact they all do the same kind of function.

Typo here:

These 3 subdivision types should be clearer on what they do and be named consistently. All of them subdivide so there's no point in calling one Subdivide and the rest not.
A button that realizes an action should not be named after an adjective like Simple or Linear. The naming should denote the action that will be realized after pressing it.

When 3 options do very similar things, we have to be verbose or use an icon or another way of representation of the results.

Example:

Subdivide Catmul-Clark
Subdivide Smooth
Subdivide Linear

What is the relationship between the Subdivide action buttons and the advanced panel?

The advanced panel specifically calls Catmul-Clark by its name, which is good, but then the subdivide button is only named Subdivide. This stablishes no relationship between the two.

If the advanced options are meant to be optionally adjusted once before the first subdivide action is done, those options should be much closer to the subdivide buttons, in the same panel. Otherwise they will always be ignored since they seem like a set of options that can be dealt with later on

In other words the logical desition order should be represented in the UI. Of course importance can be lowered by adding advanced options under collapsed sections.

Thanks for the feedback.

In D8187#208993, @Daniel Salazar (zanqdo) wrote:

Use Level as a separate title label at the top or add it to all the options like:

Viewport Level
Sculpt Level
Render level

Having only Level Viewport and the rest without the level word makes it seem like they are all different types of functionalities, but in fact they all do the same kind of function.

Aligned columns of buttons are related everywhere in Blender's interface, and this sort of set of labels is everywhere in Blender, so I don't see this as a problem.

Typo here:

Wow, yikes, good catch. I'll fix that today.

These 3 subdivision types should be clearer on what they do and be named consistently. All of them subdivide so there's no point in calling one Subdivide and the rest not.
A button that realizes an action should not be named after an adjective like Simple or Linear. The naming should denote the action that will be realized after pressing it.

When 3 options do very similar things, we have to be verbose or use an icon or another way of representation of the results.

Example:

Subdivide Catmul-Clark
Subdivide Smooth
Subdivide Linear

I could go either way here, the buttons are clearly related, with the Linear and Smooth buttons clearly acting as children of the larger one. That said, I wouldn't be opposed to repeating the word "Subdivide."

What is the relationship between the Subdivide action buttons and the advanced panel?

The advanced panel specifically calls Catmul-Clark by its name, which is good, but then the subdivide button is only named Subdivide. This stablishes no relationship between the two.

If the advanced options are meant to be optionally adjusted once before the first subdivide action is done, those options should be much closer to the subdivide buttons, in the same panel. Otherwise they will always be ignored since they seem like a set of options that can be dealt with later on

The toggle is basically just a leftover control from before there were the other two subdivision types above. There's actually a patch to remove it, D8436. In practice it's not really useful though.