2. Create a new list in that set (the set is already selected as current after creation)
3. List is created, but instead of the expected set, some B2 is opened and the list is stored there. Also, I had no such set as B2 at all in my profile.
Note: That B2 set cannot be renamed, as it does not belong to me, I assume.
My guess would be that there is an overflow in the table responsible for the list-set relation which causes all the lists be linked to the B2 set if their target set id was > 65535. As for example, in my case, new set has ID=65801
Oh, I see the issue. I think any programmer might see those numbers above and take a guess as to what happened (I'll give you a hint database table int limit).
So, I've fixed the original issue - the set_id's now have plenty of room to grow.
Now, there is not a great way to fix the ones that are bound to the wrong set_ids. I do not have the original data that shows which set_id to assign it to, but I can make a best guess, then you will each be able to adjust it if need be.
I am going through now to fix that issue, but if you want to jump in and try changing the set/group yourself, it will not interfere with what I'm doing, nor will my script overwrite the changes you make.
