Imho, this is still adding com_fields specific code to com_categories. Just veiled in the layout and "outsourced" to the CountItems methods of the extensions. As far as I see it will have no use for other cases.

And we still have issues like references to categories in the field group form

Or category options which are useless in fields groups context (associations, images, metadata, author, robots, alternative layouts, ...). Basically only the description is used and that one is stripped from HTML while it is an editor field.

So it still doesn't solve the issue of misusing com_categories for com_fields.

Not only the description is used. All the stuff around like title, publishing options, status and all the rest of the fields. Also the toolbar is given with all the filters in the list view. Implementing ACL inheritance would be only a few lines of code then.

If you really want to write it again, then you are going to copy com_categories at the end. Would be interesting to see who is doing that to match the release date of 3.7.

Not only the description is used. All the stuff around like title, publishing options, status and all the rest of the fields.

Yes sure, the standard fields every item has. I was trying to refer to the more category specific ones.

If you really want to write it again, then you are going to copy com_categories at the end. Would be interesting to see who is doing that to match the release date of 3.7.

Yes, it may be similar code to com_categories, but not the same. It will be simpler and more specific to com_fields. Like almost every extensions has similar code to com_content or com_contact.

Would be interesting to see who is doing that to match the release date of 3.7.

If not for 3.7, then for 3.8. We're not forced to ship com_fields with Joomla 3.7, even when it is merged already. So the release of 3.7 is no argument of making compromises in code. We did that mistake in earlier releases and should not make it again.

It is not a compromise, it is a reuse of com_categories.

If not for 3.7, then for 3.8

I terms of trust and professionality this would be a bad sign to the Joomla community. Marketing would not love it.

In terms of trust and professionality it would be bad for our community to send out broken code again. We're still cleaning up the mess tags introduced.

I'm just saying that as a passerby, FWIW. I haven't looked at or touched anything fields related, so I really don't know what kind of shape its in or what this coupling between fields and categories is. But we as a project have a terrible history of shipping broken integrations (tags, SQL Server support, PostgreSQL support, Smart Search) under the premise of "we can improve it later" instead of getting features to a functionally acceptable state. This really needs to stop, so I'd suggest if folks are saying there are issues with how something is done then perhaps alternatives really need to be looked at, instead of (based on what I'm reading I'm taking a wild guess here) "repurposing" the categories component to support some kind of grouping structure that isn't categories for the fields integration.

Don't get me wrong, I really appreciate what all here are doing and I'm sure that all people who are against using com_categories will have their valid arguments as I have my arguments why I'v reused com_categories.
My concern is more that nobody will do the grouping code. Simple as that. Waiting is for me no acceptable solution.

Can this be closed as we have #13019 or is it addressing something else?