run script will execute a script in a separate AppleScript instance. Therefore, it won’t have access to any of the variables you define in your main script.
AppleScript identifiers can’t be created or modified at run time, without creating a separate AppleScript instance. Even then, this trick will let you generate identifiers that belong to some parent data structure (i.e. properties in a record), but it won’t give you access to anything at the top-level.
Once you’ve created a record with on-the-fly property names, you are then faced with the problem of how another part of your script then references these property names. If it already knew what the identifiers were going to be, you wouldn’t have needed a trick to generate them; if you didn’t know ahead of time, then you will have to perform another similar manoeuvre every time your script needs to retrieve a property from that record.
There are legitimate, worthwhile instances where one needs to create a record with custom property names during run time. Probably the best way to do so would be:
(current application's NSDictionary's dictionaryWithObjects:{2, "3"} forKeys:{"a", "b"}) as record
--> {a: 2, b: "3"}
A slightly hack-y way, but marginally less so than run script is:
set f to "/tmp/reco"
close access (open for access f)
set eof of f to 0
write {«class usrf»:{"a", 2, "b", "3"}} to f
read f as "reco" --> {a: 2, b: "3"}
A third way would involve property lists.
If you really need to have variable names generated on the fly (and I can’t think why one would), you’ll have to create your AppleScript on the fly, which is probably then best done via the command line, then executed using osascript, otherwise you’ll be creating and destroying AppleScript instances all over the place, which feels a bit wasteful.