As to why strategy A fails: get_image_file_system() tries to exclusively open LoadedImage protocol on the handle, which you already have open in this test function.

Personally, I am not a fan of seeing this crate throwing exclusive opening of protocols down everyone's throat.

This is what the spec says about exclusive opening:

EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol
interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver’s
Stop() function.

This does not sound like something you'd wanna be doing willy-nilly with any protocol you may wanna open. I can also see child EFI apps not being able to open their own LoadedImage protocol just because the parent didn't bother to put their use of it inside a scope to force dropping it before starting the child.

There is also the matter of firmware/drivers already having an exclusive handle to something (I cannot get a GOP handle exclusively on my ASUS firmware + nvidia combo for example). So nudging everyone to use exclusive mode is just gonna result in a lot of annoyance.

Yes, the spec is annoyingly vague about all these protocol opening things. But the fact is, everyone on the C-side uses the old HandleProtocol or OpenProtocol+GET_PROTOCOL and it seems to work in practice.

Thanks very much @medhefgo for your help and advices! I've updated the PR.
Also what you've mentioned about open_protocol_exclusive is a very good point. Thanks for the input!

Personally, I am not a fan of seeing this crate throwing exclusive opening of protocols down everyone's throat.

Well, that's a bit extreme :) For cases where you don't want an exclusive protocol, open_protocol can be used. We don't force anyone to open in exclusive mode.

One note, there will be overlap between this test and https://github.com/rust-osdev/uefi-rs/pull/793/files for testing shell protocols. I'm not necessarily opposed to having a bit of duplication in the tests though, just pointing it out.

Well, that's a bit extreme :) For cases where you don't want an exclusive protocol, open_protocol can be used. We don't force anyone to open in exclusive mode.

Any rust programmer worth their salt will use the non-unsafe interface, that's as good as forcing them (especially when the unsafe version is also unergonomic wrt to parameters to pass). Whether that interface is better/does the right thing is the question.

Any rust programmer worth their salt will use the non-unsafe interface, that's as good as forcing them

I agree, that's a valid point. Cognitive load is already relatively high (削除) in this crate (削除ここまで) when working with UEFI. So users will refrain from using more "unsafety" when there are "safe" interfaces