Hmm, your transparency analogy is kinda convincing, but it still seems to me that even if A/B is 100% opaque, that second slash is still reducing its contribution to 75%, and C gets the rest. What am I misunderstanding?
Funnily, I get your answer to (A/B)/C as my answer to A/(B/C).
"X is (100%) opaque" ≡ "any image covered by X of won't be visible at all" ...agreed? 
Substitute A/B for X: "A/B is opaque" = "any image covered by the A/B combo won't be visible at all".
BTW "A/B is opaque' ≡ "A is opaque" ∨ "B is opaque"
Then your answer to A/(B/C) must be correct, since (A/B)/C ≡ A/(B/C) - the associative property.
And, indeed, it's simpler to reason bottom-up than top-down, especially when the bottom is opaque, so any combination of the bottom layer with any number of layers on top of it will also be opaque; in which case ...
A'X/Y = A'X + (1 - A'X) × A'Y
RGBX/Y = ( A'X × RGBX + (1 - A'X) × A’Y × RGBY) / A'X/Y
... by substituting 1 for A'Y can be simplified to:
A'X/Y = 1
RGBX/Y = A'X × RGBX + (1 - A'X) × RGBY
You can't use the thing you're trying to prove in the proof!
The part about if A is opaque then B doesn't contribute to A/B is pretty convincing, but if A is 75% opaque, as in my example, then B does contribute, at 25%, to A/B.
???
(A/B)/C = A/(B*C)
Are you multiplying RGB(A) vectors? Just multiplying opacities?
I'm not. I refer to the associative property as a fact, as proven by the "kinda convincing" glued-together overhead transparencies analogy.
I take it you're claiming the contribution of the lower image's color (RGBB) to the color of the composite (RGBA/B) is independent of the lower image's opacity (A'B). Since we're talking logic, enter Reductio ad absurdum: what if A'B = 0 (B is fully transparent)?
This makes an extra item for my list of Requirements (in the OP): if an image is fully transparent, it is to be ignoreddoesn't exist.
In this context, "A/B" signifies: "image A covering image B". I couldn't ready find a fitting symbol, so I decided to use "/", not aware of this contradiction with its ordinary interpretation as "divided by". 
In hindsight I should've used some exotic symbol instead, like: "A ꙮ B"
This is another reason I think you should group right to left. When you talk about A/B you're really talking about A/B/background; this pileup of colors happens on the stage, not in the air. So if A's opacity is 75%, then A's color contributes 75% of the total, and B/background contributes the other 25%. And, yes, the background is opaque, so I think B/bg (tired of spelling it out) is opaque, so when we stick A in front of that, we don't have to worry about the opacity of B; we are presented with an opaque color that's some function of RGBB and RGBbg and AB. But A doesn't have to worry about computing that function; it's already been computed.
You, on the other hand, are happy to stick A in front of B in midair, allowing for the possibility that the opacity of A/B can be less than 1 (less than 100% in other words). And then for my 75% example, B would be responsible for 25% of the total, but it would contribute only 25% × 75%, and the other 25% × 25% would have no known RGB values; the entire A/B would have opacity AA+(1-AA)×AB.
Okay, I believe you, although I don't know what it means to ask about the RGB values of the pile of transparencies, until you shine a light through the pile onto an opaque wall.
My point was to understand how overlapping images can be combined, using the RGBA-system. Building a stack from an opaque background makes for a relatively simple solution. Now however I have learned even how to replace several images on top of each other with a single image having the same properties as the stack, e.g. for easy and compact storage and eventual application as a self-contained building block.
I’d like to thank you (@bh) and @dardoro) for your critical reviews and suggestions!
Cool! Congratulations.
And you're welcome.