Unfortunately, this is yet another thing where UI schemas (of some sort) would be helpful. See T370534: Decision on how UI schema abstraction should work. I would really like to get to them (preferably, when @Sgs is back in office) :)).

CC @KStoller-WMF @DMburugu

I agree that this would be very useful to add clearer sections.

Is there a simpler way to accomplish something similar? Is the schema abstraction work necessary, or could we do something basic like support the ability to add in horizontal dividers between logical groups to help users visually segment the page?

In T430794#12110013, @KStoller-WMF wrote:

Is there a simpler way to accomplish something similar? Is the schema abstraction work necessary, or could we do something basic like support the ability to add in horizontal dividers between logical groups to help users visually segment the page?

Unfortunately, not really. We currently don't have any place at all to put design-related information. The only thing we currently have is a JSON schema, which defines "what kind of a value is expected" (is this a page title? Commons file name? a boolean? a string? a number? can it be negative? is there a min/max value? etc), but it cannot group various values together (or make any other sort of decisions). The MediaWiki-specific types are our own extension (and not supported by JSON schema as defined upstream), but it still impacts what value is expected, not how it is displayed.

For display, we currently dump everything one after another. To change that, we need to invent a secondary place, where we can put design-related information (what fields go with what fields). The initial version of UI schema can probably be relatively simplistic (and just allow groupings, for example), but without introducing some place to put design-related information, we can't really move forward with tasks similar to this.

Of course, I'm curious to hear @Michael's perspective on this as well.

Thanks for the explanation! I was hoping there might be a simpler solution, but it sounds like there may not be in this case.
Michael has also started a broader discussion around T370534: Decision on how UI schema abstraction should work and the long-term ownership of Community Configuration. I would personally love to see WMF continue investing in Community Configuration. It has already helped multiple teams scale more quickly, involve communities more directly, and provide a more consistent, standardized way for communities to configure the features we build.

The challenge for Growth is that Community Configuration sits outside our core audience focus of newcomers, which means it also falls outside the annual plan initiatives we are accountable for. That makes it difficult for us to prioritize, even though I think it delivers significant value across the movement.