This would be useful since most datasets would use many external identifiers and can be time consuming to add them to MediaWiki:Wikibase-SortedProperties along with having to add the other properties to stop external identifiers coming before other properties, could also be useful if you could add statement groups for properties other than external identifiers as it is possible in regular wikibase installs but external identifiers would probably be the most used.

$wgWBRepoSettings['statementSections'] is the setting that would need to be set for cloud wikis.

On wikidata this looks something like this:

'item' => [
			'statements' => null,
			'identifiers' => [
				'type' => 'dataType',
				'dataTypes' => [ 'external-id' ],
			],
		],
		'property' => [
			'statements' => null,
			'constraints' => [
				'type' => 'propertySet',
				'propertyIds' => [ 'P2302' ],
			],
		],
	],

It could also be an idea for this to make its way into the default wikibase settings if folks think that makes sense

In T310898#8148146, @Addshore wrote:

It could also be an idea for this to make its way into the default wikibase settings if folks think that makes sense

I think this would be most expected / wanted property order, I doubt anyone would want external ids mixed in with defining properties

If $wgWBRepoSettings['statementSections'] is set for cloud wikis, will it be possible to overrule this setting by adding a custom property ordering page such as https://kbtestwikibase.wikibase.cloud/wiki/MediaWiki:Wikibase-SortedProperties ?

In T310898#8164510, @OlafJanssen wrote:

If $wgWBRepoSettings['statementSections'] is set for cloud wikis, will it be possible to overrule this setting by adding a custom property ordering page such as https://kbtestwikibase.wikibase.cloud/wiki/MediaWiki:Wikibase-SortedProperties ?

The sorted properties page will allow sorted of properties within sections, but not the creation of alteration of sections themselves as it stands

This would be a great feature as otherwise the item page may often look cluttered even though the properties can be (on the Wikibase-SortedProperties page) ordered in such a way that non-identifier properties are listed first and then followed by the identifiers (as @OlafJanssen and @Addshore have already mentioned in the comment above). I would certainly use this feature once it is available :-).

We should think about this one a little bit. Not all claims with ExternalID properties are identifiers for an item, in that they do not represent a same as type of relationship. The visual presentation in WD seems to suggest this, and I don't think I would want it applied universally to all wb.c instances. An alternative would be to add more sophistication to the wiki page method of setting property order to use any number of section headings.

Yes, it may be worth considering adding the functionality which would let users create custom clusters of properties. E.g., a little while ago I was just adding similarly constructed links (using the External ID datatype) which are in fact URLs pointing to lists of publications in a library catalog (these URLs use author IDs as search parameter and this ID is what I add as a value while the remaining part of the URL is adding from the formatting URL property value). In this case it may be useful to have a separate property cluster entitled e.g. Publication Lists.

This is related to the work around feature parity and simplifying ontology federation (CC @Leif_WMDE )
To be discussed with @Lydia_Pintscher what behavior we want, what should be default or configurable on different kinds of Wikibases.

In T310898#11009046, @Anton.Kokh wrote:

This is related to the work around feature parity and simplifying ontology federation (CC @Leif_WMDE )
To be discussed with @Lydia_Pintscher what behavior we want, what should be default or configurable on different kinds of Wikibases.

My thoughts: We should continue to have the flexibility in configuration that we have right now but we should change the default to be the same as Wikidata: external IDs in a separate section and constraints in a separate section.