drush config:import and drush config:status always report the configuration is different when ignoring specific keys (config sorting)

This is an issue with the beta version as running perfectly with 2.4 previous version

Refer behaviour

on 2.4

on beta version

I am seeing the same issue in my project when ignoring the description key on fields. This is causing our builds to fail because we have a step that checks that configuration was imported correctly.

When running drush cim --no --diff I see something like the following:

diff --git a/tmp/drush_tmp_1679421962_6419f20a98484/field.field.node.article.space_term.yml b/tmp/drush_tmp_1679421964_6419f20c4a00d/field.field.node.article.space_term.yml
index a7e6af484..792564d13 100644
--- a/tmp/drush_tmp_1679421962_6419f20a98484/field.field.node.article.space_term.yml
+++ b/tmp/drush_tmp_1679421964_6419f20c4a00d/field.field.node.article.space_term.yml
@@ -10,7 +10,6 @@ field_name: space_term
 entity_type: node
 bundle: article
 label: 'Space'
-description: 'Space'
 required: false
 translatable: false
 default_value: {  }
@@ -19,3 +18,4 @@ settings:
   handler: 'default:taxonomy_term'
   handler_settings: {  }
 field_type: entity_reference
+description: 'Space'

This is interesting!
This happens because the config compared is not properly sorted. I encountered this issue with config split too. I think this is something that core should fix. I will have to find core issues and link things together.
Unfortunately sorting things may or may not be so easy because of the missing orderby information on sequences.
But the example here would benefit from sorting of the mappings.

We can do a simple order the way it is when ignoring keys I think.

I tried to reproduce this issue by changing the UUID of media.type.image and then running drush cim. I observed that one configuration was deleted and another was created.
Next, I added media.type.image:uuid to the ignore list and ran drush cim again. It showed me that there were no changes to import.

@bircher, please let me know if I missed anything while reproducing the issue. However, I believe this issue may not exist in the latest version, 8.x-3.x-dev.

No I think it can still happen. The problem is that the config needs to be sorted and this is currently an unsolved core issue. So I would keep this issue open so that people find it and don't open a new one.