Seeing it now, and I thank you.  I had always read that explanation to refer to <select name="...  where multiple is an option, and that you used oHtml:getVar() to retrieve the values of any variable.  I have only seen <input type="... to refer to NAME-VALUE pairs, which I understood to mean one-to-one.  It wasn't that :getVar() could read an array that surprised me; it was that <input> could write an array. 
 
The fact that the web browser assigns an array of character strings should be the lead in the story, but, instead, it was buried at the bottom. I think I know why.  If you are hand coding screens in Frontpage, this array feature doesn't matter, because you are creating the screen line by line, even in visual mode, and you give each variable a unique name.  But with the power of WAA and looping code, we are building big dynamic pages and naming page variables from almost zero effort.  This approach makes a row/column data browser a piece of cake, a project of ten lines or so.  And it makes gathering in the data and storing it just as easy and a lot less prone to buggy code.  Any html screen created from more than one record in a dbf can probably benefit from taking an array approach.