There is a lot going on here, and while you've done a good job of trying to show and explain your permissions and PREMIS right settings, I'm still a bit confused about the outcome, and how best to reproduce. I will try to do some testing based on what I understand. However, I'm not surprised to hear that there might be some inconsistencies here with so many different conflicting rights and permissions.
First, there are some known issues with the Permissions module that could be impacting this that are not easy for us to resolve without a complete overhaul of the permissions module. I've described these previously in other threads, such as:
The short version is that AtoM's permissions module uses a very old library with known issues, and fixing them all will likely require us to replace the entire permissions module - work that will require community sponsorship for us to be able to undertake. So far no institution has sponsored this work. For more information on how we maintain and develop AtoM, please see:
With the PREMIS rights, it's important to remember that only one Act can be actionable at a time - so the "License > display = conditional" rights statement is not having an actionable effect if you've set Discover as the actionable act.
Finally, it's possible that the issue you're describing is actually just a result of the full-width treeview not fully updating the page during navigation. With the sidebar treeview, clicking any level will cause a full page reload to show the newly selected resource. With the full-width treeview, we use AJAX to update just the parts of the page that change - though it's possible that not all components are properly included in this refresh. Here is an example of a similar issue we fixed in the 2.5 release, where the breadcrumb on the view page was not being updated:
Does doing a hard refresh of the page fix the issue? You can usually do this by pressing CTRL+SHIFT+R to reload the page after navigating in the full-width treeview. If that fixes the issue and properly displays the carousel, then this suggests that the problem is with the treeview's partial page loading, and that we need to ensure that the carousel component gets updated as well.
Next, I can see this is test data, but I wonder if it might help to make your fonds top-level descriptions, rather than part of a larger hierarchy, so you can better control the permissions associated with the fonds using less inherited rules that might conflict?
In any case, I think I understand the issue enough to try to reproduce - you've got PREMIS rights affecting items that are preventing their thumbnails from showing in the carousel at higher levels, when they shouldn't be - is that correct? If so, I will see if I can reproduce, and I will file a bug ticket if necessary. There's no guarantee we will be able to fix it in an upcoming release until we know the source and scope of the issue, but reproducing the problem will be our first step. I will let you know what I'm able to find via testing.