mekonbekon is right on both counts.
When a table is created it's added to a dictionary, using the name as a key, and is set as the "active" table. Using "Set probability table" gets the one with the given name from the dictionary and sets it as the "active" table. The weighted expression always uses the "active" table.
Entries in a probability table are not unique, you can have multiple ones with the same name and/or weight. The reasoning is that it allows you to merge multiple lists into a single table, without having to look for and merge duplicates. You can pass a weight of "0" in and it will remove the first entry with a matching name. It gives more flexibility, but I never decided if it was more complex than what people needed it for.
In terms of other stuff you've chatted about, there is probably some room for polish. While it was something we considered useful we got fairly minimal feedback at the time it was released, so it hasn't been adjusted much.
You can't change the weight of an entry after it's been created, but you can always remove it and add a new one with a higher value.
Importing from JSON might be nice, but it's quite easy to do with a for loop already ( parse JSON, for each: add probability entry ).
I did consider adding a variation of "Weighted" that also took a table name, but again it's quite easy to do without. It's easy to bloat plugins with too many features and ACEs, which then makes them hard to maintain. Unless something is impossible to do, or it's a really useful shortcut we avoid adding such features.
One thing that does occur to me as useful would be the ability to read all the entries in the table, so that it can be serialized for later ( if for example certain drops were removed after being obtained and you wanted that to be preserved without having to keep another list somewhere ).