Yes. That stuff causes all sorts of problems. These are not, in database design lingo, independent. For example, there are no dependencies on using a pad as both a sleeping pad and for a frame in your pack. When you are hiking, I have never envisioned needing one for sleeping. (I never use a sit pad, usually just stopping on my feet to rest a bit, maybe 5 minutes to eat a snack and drink some water, then move on.) Conversly, while sleeping, I have no use for one for stiffening the pack. They are different activities. You can therefore use a pad as a frame in a pack with no loss of functionality for either activity. They are activity independent.
Not so if you use a spoon as a stake. In a rain storm, I cook under my tarp and NEED my spoon for coffee/cocoa and for eating. If I pull the stake, the tarp falls down. These are DEPENDENT. You cannot cook & eat while your tarp is up and staked out. Using a spoon as a stake DEPENDS on whether you need it for cooking.
It is possible to plot out your items and your possible activities in a Ven diagram. wherever you have multiple connections to the same piece of gear, you cannot use that piece of gear for the conflicting activities. Follow?
This is straight out of logic design/data base normalization and, is 100% applicable to backpacking this way. In logic design, you would have long sets of "and"/"not" equations. A Ven diagram is a proof for logic, because it can be converted to the logical formula, directly, ie a logical proof. Depending on what you are doing, just choose the appropriate methode. This will let you avoid all of these multiple use binds as you call them. Worth the effort? Well, depends on wether you can sleep cold or with a pillow, when you cannot do both (as an example.) You should know to carry the lightest item, resolving the conflict, before you need to resolve both.