I had the account there for a long time, and at that time gdrive wasn't available (or I didn't know about it) and for me it produced the fastest upload and download speeds while being relatively "clean" compared to other more "shady" sharing sites. Never had a problem with it.
They are intended to be different approaches / implementations of the same thing, more or less. The OP didn't prefer the "old", "arbitrary" variant because he needed to scroll and such and the "gaps" of hidden hexes made that difficult (though not impossible), so the idea was to recreate what that variant did, but leaving no hidden hexes in the "sequence". The difference is in terms of code, not necessarily functional.
Yeah, I had the same ideas about resequencing, just didn't know which variant to choose (or which of them the OP would prefer), i.e. the "last" or the "current" one, when it came to texts and images, which is why I left that part unfinished.
As you could see, the "last" variant produces a visible "shift" of hexes and associated info (e.g. 1 <- 2, 2 <- 3, 3 <- 4), which might not be desirable, depending on what is the expected behavior. On the other hand, the "current" variant looks more natural on the visual side, but you could argue that it visually leaves gaps as well (although technically it doesn't), since removing an "inside" hex like 2 from a 1,2,3,4 list basically means that subsequent numbering / imaging the hexes would start at 5 and number 2 would be impossible to place again.
On top of that, there is the problem of where to continue the numbering from after you remove 2 from 1,2,3,4: while for the "last" variant that is clear because the list becomes both technically and visually 1,2,3 so it would continue at 4, for the "current" one, since the list visually becomes 1,3,4 (although technically it's still 1,2,3 in terms of shown meters) it isn't clear if subsequent numbering should start at 2 (in effect toggling it before going further with future placements) or at 5 (meaning continuing after 4, but without being able to put back the 2 on screen ever again unless you start over).
The original "gap" / "arbitrary" variant was much more clear / natural from that point of view and honestly I didn't fully understood why the OP wanted an "uninterrupted" list since it's a fact of life that if you remove something from the "middle", you'll have gaps as a result. The scrolling / selecting / whetever he talked about could have been done even with gaps being present, and if he wanted to write / save somewhere an uninterrupted list he could have done so, both of them by having a string list with the "active" / "shown" hex indexes, in which the "resequenced" / "uninterrupted" index would be the position of the active hex in the list, e.g. removing 2 from an 1,2,3,4 list results in an active hex index list of 1,3,4 so the "resequenced" index of 3 is its position in 1,3,4, aka 2.
Also, his workaround of removing the last hex no matter which hex you click on presented in the last code he posted feels a bit unnatural to me as well - but then, if he feels it's good, then that's it, I'm not the one that decides on this.
I disagree. Lua is a scripting language whose evolution / features / etc. are totally independent from Rainmeter, and the syntaxes differ considerably. Lua is not native to Rainmeter just as it isn't native to C or any other "main" language using its scripting / embedding capabilities. RunCommand, on the other hand, is a plugin that can be used in Rainmeter just like any other plugin, despite the fact that it triggers running external programs. Saying Lua is native to Rainmeter and RunCommand is not is like saying 3rd party software that does, say, painting, e.g. Photoshop, is "native" to Windows while MSPaint is not. Anyway, that's not particularly important, it's more like a semantical / technical thing to debate on, and doesn't affect in any way the fact that Lua (or any scripting language) is quite useful to any "main framework" that embeds it (including Rainmeter).