I'm having trouble reproducing this problem.
Even though I put the files in the same directory, when I open the file I am faced with hundreds of warnings starting with:

Info: Read library:  'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', '//..\..\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', parent '<direct>'
Warning: Cannot find lib 'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend'

To resolve this I go to Outliner -> Blend File, I run the operator to relocate the missing library.
All warnings appear to have been resolved after that.
But I can't follow the steps listed because P-root has no "local Copy Transforms constraint" :\

I don't know this area very well.
I could recreate the directory, but is there another way to reproduce the problem?

My bad, it seems one of the files I uploaded was the wrong one, sorry! I updated the file, the reproduction steps should be valid now - P-root should have a "Copy Transforms" bone constraint:

Indeed, at first I was trying to hunt down some setting that might trigger this to happen, but even just deleting most of the bones from the armature makes the issue go away which left me pretty confused.

Also just to note, this issue is not important for the studio, there are no (current) plans to convert old files from proxies to overrides - I was just making a demo video of the feature for the 2.91 release and ran into this, that's all.

the order of bones in proxy and linked objects and armature is not the same ... Not sure how this happens and this will definitively break overrides.

C.object.pose.bones[0] == bpy.data.objects['CH-pastor.5_proxy'].pose.bones["root"]
C.object.proxy.pose.bones[0] == bpy.data.objects['RIG-pastor.5'].pose.bones["ORG-Thigh.L"]
C.object.data.bones[0] == bpy.data.armatures['Data_RIG-pastor'].bones["P-root"]

So would consider this as 'not a bug/known issue'

known issue is useful for keeping track of tasks and merge reports with similar problems.
Since we don't know what caused this unusual bone order, I think it is better to close the task (maybe related problems can be reported in the future and this will also be fixed).

Interesting! If parts of Blender will continue to rely on those indices being in sync though then this might still be worth hunting down, even if it's too late for existing armatures.

After some fiddling around with turning X-Mirror off and on while deleting and duplicating bones and switching between edit and object mode, I can sometimes get the indices to fall out of sync, although not sure of exact reproduction steps, but I think having more bones helps.
In this blend file:

• Run the script in the text editor to see the indices are in sync.
• Enter edit mode
• Delete the selected bones
• Disable X-Mirror
• Duplicate a bunch of bones
• Enter object mode
• Run the script again -> indices are now out of sync.

If this seems worthwhile let me know and I can either update this task or open a new one.

But on another note, I find it unfortunate that anything should rely on these indices rather than the bone's names, since the user can't control the bone order anyways. I think whatever relies on this will just end up behaving arbitrarily as far as the user in concerned.

I'm more interested in hearing from other devs in Animation & Rigging whether this is expected.

Difference in order between posebones and bones in Armature obdata may be expected (the former are in a flat list, the later in a recursive/tree-like set of lists), and is probably not an issue.

But reading again BKE_pose_rebuild, this function does not ensure any kind of deterministic order for the posebones. This is going to be a critical issue with overrides (unless we do a full name-based search in diffing code, but this will be expensive, even with the GHash integrated in poses). So I would suggest changing BKE_pose_channel_verify to ensure a consistent and predictive order of posebones in their list (should not be too hard of a change I think).

I mean if the result is losing the constrains created locally in the animation file then it is a bug.

If I understand it well, this could mean even not touching a bone involved in said constrain could cause that connection to be lost due to the reordering of the indices.

If that's the case then it should be fixed.

Sorry if I misunderstood the issue, just point it out if i did :)

@Luciano Muñoz Sessarego (looch) override code expects matching order of bones in reference (linked) object pose and local (override) object pose. Just like for any collection (besides the very few that currently support insertion of local items, like constraints or modifiers). I'd say that this is a reasonable expectation...