Hello Alex_Scerus ,
Please find my replies inline.
This should be clearly mentioned within the official migration docs and in here -> Yes I can work to post them on our official article after confirming this information with public folder engineering team.
It looks like that we are currently having issues hierarchy sync issues… and my feeling is that this is being caused by the size of the hierarchy and the number of mailboxes trying to pull the hierarchy from the primary hierarchy. -> Normal to have if you have huge hierarchies and if you have more than 100 public folder mailbox you can expect to see hierarchy read replace public folder mailboxes which is acting as a middle tier between secondary public folder mailbox es and your root public folder mailbox to avoid any over-exhaustion on your root primary public folder mailbox. https://techcommunity.microsoft.com/t5/exchange-team-blog/help-us-scale-public-folder-hierarchy-in-exchange-online/ba-p/922664
So, I am interested in the relationship between the different attributes, sync states in PF diagnostic logs, conditions, which will trigger a Public Folder mailbox to become HierarchyReady and being offered to the end-user. -> The conditions is when IsHierarhcyReady set to True and IsExcludedfromServingHierarchy is set to False and that is described on the article.
https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-public-folder-deployment-best-practices/ba-p/606172
If the PublicFolderInvalidDumpsterFixingProcessor created and attached 242k “dumpster” right after the migration… my understanding is that this also is some kind of hierarchy change, which has to be replicated to every pf mailbox? -> Yes it's, to update DumpsterEntryID across all requested PublicFolders
Let me know if you have further concerns.
Regards,
Hazem