Thanks for the reply
I'm just saying that I quickly became frustrated with the behavior because I did not understand it ("other layers" being guides (or not) or being editable (or not) or visible (or not) in the plan view). So much so, I felt the need to get the source code to understand "why".

It will make the program too complicated, because you would have to detail also in which other levels you want a level to be visible, otherwise you would get many guides for houses with multiple levels.
You could simply copy paste walls from a level to another one and remove the ones you don't want to keep, or program you own version, as you decided to do.

I agree that layer attributes may be "too cumbersome" and I would like to have a coherent set of rules for displaying the guides. I'm thinking through it...perhaps analyzing all walls on a level (to determine a level "height" and presenting as guides any other walls from any other level that intersect that level. I am trying to understand the reasoning for allowing "other level" walls being "editable" if they intersect...is that typically desirable?

No, you missed the fact that levels are always ordered from the lowest level to the highest, then at the same elevation, in the elevationIndex order set in the level modification dialog with the arrows at the right of Levels summary list.

I understand that layers are being ordered as modified, the "specialness" of "layer0" was one area of confusion regarding whether guides were from levels "below" or "above"...as the elevation of "layer0" is modifiable, therefore the plan view presentation can change radically based on its elevation relative to other levels.

What principles do you have in mind?

Well...I shouldn't have to read source code to understand behavior [;)]
I sincerely appreciate the effort that you have put into this tool and am quite happy to have found it. I'm just suggesting that perhaps there are some rough edges in behavior.
From a principle standpoint, "reciprocity","orthogonality" (whatever term you like) and "consistency" seem violated.
For example, in the below video, levels at same elevation don't even present depending on "elevationIndex"...level 0/1, 2/3 at same level, yet 1 not visible from level 0, 3 not visible from level 2...yet higher levels presented as guides. Adding a level can remove existing levels from being usable as guides, etc.
...Having gone through the code, I understand why things are behaving as they do, but I don't necessarily agree that this is optimal behavior.

https://youtu.be/BiiOhdZmcY0