Sorry I didn't make that part very clear. The "attachments" rest... basically all arguments after the selector? Can be an array, object, string, number or node.

If it's an array, it's the arguments to be passed to __make to create a new child.

if it's string, number, or instanceof node, it's appended.

But a generic non-node object? That's attributes.

So for example if you want the halfwitted time-wasting aria-role bullshit:

make("div", { role : "form" });

Because I'm "loose juggling" -- embracing loose typecasting instead of fighting it -- the argument TYPE determines what to do with it. Fun part is with the attribute "stores" you can declare multiple instances of it, and they'll layer. Where you place the { attribute : value } type objects in the "attach" order doesn't really matter.

Though I have no clue what you mean by "mirrored" -- are you referring to reflections? If so I'm not sure how that applies to or would involve this.

The next version also uses setAttribute for string/number values, and thus you could set something like "aria-disabled' and it'll work. Assuming you're disabiling a non-interactable instead of just using the correct tag and setting the normal disabled property.

But that's why ARIA is ignorant incompetent bullshit that was the start of my loss of faith in the WAI.

Seriously though, look at the table example? See how colspan is set on the tfoot>th? Yeah, that. Standard attributes can be passed as an object, because the TYPE of the argument determines the behavior.