It’s better to delay a feature that causes a conflict with an already existing feature, and discuss the best solution first, than to introduce it anyway just for the sake of it and cause confusion and messiness.
No need to hurry. Blender is already introducing more features than ever with each release.
Can elaborate about the conflict you find in that specific patch?
Unless I’ve understood it incorrectly, right now Pablo is developing Sculpt Face Groups parallel to the already existing Face Maps, which offer similar functionality. I think it would be better to assimilate them, for the benefit of Blender-wide universal use (e.g. for third-party add-ons), and to avoid clutter and confusion.
I also think being able to have overlapping faces in different Face Maps / Groups would make them more powerful than ZBrush Polygroups.
But this is just my personal humble opinion. 
I don’t really follow what the issue with it is. I just hope it doesn’t turn out like Cycles baking, where it worked well all through development and then at the 11th hour before merging was crippled.
The Vertex Paint patch seems to have some clumsy UI/UX conflicts, but I don’t see any notable UI/UX issues in the Face Groups other than perhaps naming.
Currently, vertex groups are used for selections. As is they can be used as temporary selections sets for modeling, for paint mask. They are used as weights groups for armature skinning, for influence of modifiers, for hair particles densities, etc…
There is a ton of applications of vertex groups and that does not disturb anybody.
We have lots operators and vertex groups modifiers to normalize vertex groups and be sure that they don’t overlap themselves.
I don’t see why developers could not do the same thing for face groups.
Being sure that face groups can be used as face maps simply imply to add some lock buttons into panel list.
But I am wondering with expected UDIM support if it would not make more sense to fuse face maps with UDIM tiles than face groups.
Wait, what? Huh? What a bizarre idea. Why would you want to fuse these two completely unrelated things?
Your point is that face maps are not overlapping Islands of faces. That is exactly same thing for UV Islands of one UVmap.
The idea behind UDIM is to set one UV Island per tile to allocate one big texture to it.
You can have as many islands as you want per tile in UDIM though? It’s just a texture file management thing. In fact you can put an island across tiles if you want. Not a great idea, but UDIM doesn’t care.
I am not thinking about management into UV Editor but into Mesh properties.
I think that we could have a unique panel Maps.
Inside this panel, for active channel, user could choose if he creates a UVmap or a Rig map.
For each UVmap, there would be settings for UDIM tiles.
For a Rig map, there would be settings for Face Islands (current face maps) instead.
And the benefit too the user would be what?
Less panels do deal with into Mesh properties tab.
But you just wrote you want different panels for different types. This is confusing.
No. I wrote a unique panel that has its display modified according to active channel.
User creates a Map channel.
Then, under list of maps, he click on one button of a two button template UVmap or Rig map.
Then settings below the list don’t have same aspect according to chosen map type.
Well that just makes it contextual.
I’ll take too much buttons any day of the week over buttons that pop up and hide from you.
It seems like you didn’t try the patch, did you?
When implementing a feature the speed is one of the most important things to have in mind, i would like to have feature that is shared all around Blender but if it slows a given workflow down i don’t really want it. I will prefer a different implement if it will make workflow faster ( i m thinking about sculpting workflow). There is also the aspect of memory usage, lately Blender is getting memory hungry, if this implementation helps to save memory why should we hold back? We have to consider as well how much work the developer has put in there.
@pablodp606 can you update that patch please i want to test it, i m getting error i believe is due to the last overlay update.
This is not a big problem, you have the a key to close and open them
Panel title continues to take space, you have to drag panel at end of tab if you don’t use it.
I am also worried about a constant confusion into upcoming discussions between face maps and face groups, if we keep 2 panels with closed aspects and closed names at same location.
If we have only one tool to create a set of faces and multiple usages. People will clearly mention what use they have in mind. And newbies following tutorial will create a face group without question and then concentrate on next step.
One can’t design UI around tutorials. That’s backwards.
Maybe people will make a mistake. That’s fine. They’ll make it once and learn from it.
You want to hide complexity by having a deeper, smaller UI, but it’s proven time and again that a shallow, broad UI is faster and easier to operate by experienced users. When you’re driving a car and want the AC, do you prefer to mess about with menus and climate settings, or do you prefer to just flip a physical switch? I definitely prefer the latter even though it makes the interior look complicated.
What’s this Overalpping Face Maps? the main goal was to use them for rigging and there is already a proof of concept addon in Blender 2.8x, this feature is not fully finished yet as it seems the Devs are focusing on other areas but if you are going to introduce some new concept that means a potential change to their design.
For anyone who is so into sculpting they gloss over the rest of Blender’s development, technical debt was a huge reason why 2.80 was delayed a year and even then was released with regressions in a few areas. The targets were ambitious and a lot was added, and in many cases it meant a huge leap forward, but you can’t just add a ton of stuff first and tie everything up later.
In this case, adding a bunch of similar but unique features and data-types for each area of Blender is a recipe for massive bloat. Then you have the issue in that a dev. would need to implement the same feature in different ways for every mode (which would be time consuming and guarantees feature disparity). If anything there needs to be more unification (such as a generic ‘selection’ backend shared between the 3D view and UV editor).