While c=1 does create a sender bias, it also has the potential to create a "player" bias, which will attempt to target players first before targeting non-player entities. A player bias is dependent on the command/feature. The only cases where a player bias occurs is with /scoreboard commands (not counting /scoreboard teams join ... or /scoreboard players tag ...) and stored CommandStats.

The solution is to prevent targeting players, such as either with the type=!Player parameter:

/execute @e[name=setter] ~ ~ ~ scoreboard players operation @e[name=getter] test = @e[type=!Player,c=1] test

Or targeting the specific type of entity with @e[type=ArmorStand]:

/execute @e[name=setter] ~ ~ ~ scoreboard players operation @e[name=getter] test = @e[type=ArmorStand,c=1] test

Nested /execute

"detect" is not a command, but rather a literal argument of the /execute command (just like "entity" is a literal argument in /stats entity ...). Syntax:

/execute <target> X Y Z detect x y z <block> <metadata> <command>

If you want to have nested "detect" functions, you need to use nested /execute commands, while using sender bias via c=1 to always ensure the executor is re-targeted, and while attempting to reduce server strain caused by expensive distance-sorting alongside a straight @e by using r=0 (though will present issues for armor stands due to MC-88533). Do not use r=0 if your base selector is @a (explained in the next section below):

/execute @e ~ ~ ~ detect ~ ~-2 ~ purpur_stairs 0 /execute @e[c=1,r=0] ~ ~ ~ detect ~ ~-9 ~0.4 red_sandstone_stairs 3 tp @e[c=1,r=0] ~ ~ ~-0.4

However, be aware that this is a potential cause for performance loss server-side, as all selectors must be re-evaluated upon every activation, running through expensive operations each time. Using a straight @e selector will severely decrease performance when used excessively in this manner. You should reduce targets as much as possible first via proper parameters such as type.

CommandStats & /testforblocks

While performance may not present as much of an issue for locating smaller structures, deeper /execute nesting will start slowing the server down. You can instead use CommandStats to detect a specific structure around the entity using /testforblocks. The downside of this is that there must be a pre-built structure in loaded chunks (primarily the spawn chunks) in order to compare to.

CommandStats are a set of triggers that will modify a score depending on the type of command an executor is running, with the score being relevant to that command. Since CommandStats can be applied to entities, that makes it multi-target friendly without having to deal with a large chain of nested /execute commands.

Prerequisites

First, the objective to hold the return value from CommandStats.

/scoreboard objectives add NearStructure dummy

Next, the CommandStat trigger to apply to targets. In this case, the "AffectedBlocks" trigger will set the executor's score equal to the number of blocks found or modified by a command (and any commands not modifying blocks will result in no change). If new targets can newly exist at any time, this may need to run on a clock.

The initial "target" is who to apply the trigger to, while the "internal target" is not processed and is stored literally as written on the target, to be temporarily processed with each relevant command execution. In this case, all players will set their own "NearStructure" scores.

@a is the only selector that can target dead players, but only if parameters r/dy/dx/dz are not specified. Using r=0 is not advised because it throws out any dead players, which can severely skew scores when dead players continue executing commands but are changing the wrong scores.

/stats entity <target> set <trigger> <internal target> <objective>
/stats entity @a set AffectedBlocks @a[c=1] NearStructure

In order for CommandStats to modify a target's score, that target must be tracked on the scoreboard prior. This may also need to run on a clock.

/scoreboard players add @a NearStructure 0

And finally, you will need to build a structure in the spawn chunks that you would want to detect.

Detection

The following must be run in numerical order on a clock.

1. Causing players to test for a structure around them. Modify the coordinates as needed so that it points to the pre-built structure as well as the relevant location around the player.

    /execute @a ~ ~ ~ /testforblocks x1 y1 z1 x2 y2 z2 X Y Z
   

2. When each player runs the /testforblocks command, they trigger their "AffectedBlocks" CommandStat, which will set the player's "NearStructure" score equal to the number of blocks matched with /testforblocks. It will be 0 for failure, or the total number of blocks in the structure upon success. You can detect a minimum score of 1 to target those players:

    /tp @a[score_NearStructure_min=1] ~ ~ ~-0.4
   

But for smaller structures, it would be much less complicated to simply use nested /execute commands.