"files stay here for the team" prevents me from moving files from team to personal folder

OK, y'all. I came to complain about discovering I can no longer create new team folders via explorer, and ended up unraveling this whole mess. Since all you get from the dropbox "staff" here is gaslighting that brand new things have actually always been that way, I'll explain it the situation.

What's happened is that a system which was formerly organized around "folders in the team space" and "private user folders" has been "generalized" into two types of "top-level folders": "team folders" and "shared folders". Previously "private user folders" were very special, and "folders in the team space" were not: you could freely create and delete them. Today, we're finding we no longer can. It's because they're all special now, just as "private user folders" used to be. It seems our accounts were migrated instantaneously into the new paradigm in the following manner:

"private user folders" -> "folder shared to a user"

"folders in the team space" -> "team folder"

Note: I am using different terminology than the web client, because dropbox staff and dropbox docs do. But the web client uses this terminology (a poor decision, IMO)

Me and DB staff and DB docs call it "Top-Level" -> Web UI calls it "Team folder"

Me calls it "Team folder" -> Web UI calls it "Team folder, who can access: everyone at ORG"

Me calls it "Shared folder" -> Web UI calls it "Team folder, who can access: specific people"

Me calls it "something someone else shared with me" -> Web UI calls "Shared folder"

(I believe dropbox has dropped the ball in clear communication here by trying to be too-friendly for something that's fundamentally complex)

Flash forward to today.

Note, you cannot create top-level folders via explorer. That's because only dropbox proprietary API has the means to specify of the new types of top-level folders it is. Moreover creating is a complex operation because it's more than just syncing filesystem data now. Consider this scenario

1. There's a top-level team folder called FOO, but you don't have access

2. Therefore, FOO is not synced to your workstation

3. On your workstation, you create FOO

4. Wait, what? with what properties? Whaaaat? There's already a top-level foo with established properties. No, no, no. This can't be allowed.

Note, you cannot rename top-level folders via explorer, for similar reasons.

Note, you cannot put files in the top-level. That just doesn't make any sense. The top-level doesn't contain those any more. What about those of us that DID have files there? Was it ever allowed? I would suspect, so. I do notice that the "content" view on the web UI (aka "the top level") has a "show deleted files" option, which is not logical, since there aren't "files" here and there's nothing that can be deleted... unless... dropbox... did they... did they dare.... delete top-level files when "migrating" us to the new scheme? It would be logical but gutsy. Anyone know?

Note, you cannot move top-level folders anywhere else, via explorer OR web UI. Conceptually, that's because top-level folders by definition are sub-typed into one of the new categories; moving it would imply removing the categorization. Technically, it's more likely because a top-level folder isn't even a thing that can be put anywhere else but the top-level.

Note, you cannot delete top-level folders via explorer. If you try, it will undo itself after a couple of seconds (without an error message, as in the case of moving via explorer; this is an error and the client needs to be fixed). That's because there is no longer deleting of top-level folders, only "archiving". Deleting is for actual content. Archiving is for top-level folders, those new special things. The desktop client can't do this, I think, because someone at Dropbox wisely decided that the user needed to be educated about the difference between archiving and deleting, and only the dropbox proprietary tools can do that. In particular, you need to know that there's no UNDELETING those things.. per se... in case you went to hunt for deleted stuff.

Note, you cannot move top-level folders anywhere else, part 2: that may also be because it implies DELETING a top level folder (or removing it, in any sense), which is also forbidden.

Now I also want to consider another horrifyingly convoluted scenario: suppose you move a top-level folder via explorer, and dropbox does a workaround for us: they create the new subdirectory name, then move all the content sub-items, then archive the top-level directory. What happens... when... we... hit ctrl+z? Or, what happens if we hit ctrl+z AFTER another admin or someone otherwise on the web UI does something to the top-level content for the team, such as creating yet another top-level folder with the same name?

Everything falls apart. Everything falls apart because the workstation filesystem is no longer the organizational authority for the dropbox content. THAT SHIP HAS SAILED, Y'ALL. SAY GOODBYE.

We're still a bit lucky: the workstation filesystem is still the organizational authority for content items UNDER A TOP-LEVEL FOLDER. If that weren't the case, I'd be shopping for a new cloud drive right now.

Note, you cannot delete..er.. archive multiple top-level folders at once. There's not necessarily any logical reason for this, but I guess it could be a bit tricky to make edits to the properties on multiple things at once.

Note, you CAN "delete" top-level items from the non-admin dropbox web view... sometimes? I did delete one just now, which I created while testing earlier, but now the "Delete" and "Rename" options are disabled in a new test; this is what I expect: only the admin console should be able to do anything with top-level folders. Still.. this is puzzling.

A workaround for this madness for most of us shall be the following:

1. never, ever create top-level folders. Create a single top-level folder called "stuff". Now inside there you can freely operate. Of course you will need to update all your scripts and pathing muscle-memory.

2. do create top-level folders to simulate "private user folders", if dropbox isn't doing that for you already.

During the research of this, I discovered a quirk in the new paradigm. I accidentally archived a valuable team folder. When unarchiving it, it came back with zero members access. That is, the properties of the top-level folder did not unarchive along with the content. IMO this is a bug, but I guess there could be a complex reason for it (perhaps the set of users has changed since it was archived, and perhaps you've added a user that you do NOT want to have access to it, but yet you had it flagged as ALL, and now that new user would accidentally have access to it).

I do not like that the method for changing the properties on a top-level folder is called "share with dropbox". I think this is a too-friendly way to invite me to share it with outside users, but really I just want to control inside access. The established UX paradigms for this are to edit properties on something, not "share" it.

I suppose it's possible that for people who have NEVER USED DROPBOX BEFORE, the new design may make more sense, but we're confused by our decades of prior experience. At this point I think we need to forget everything we know and suffer through some basic introductory "how to dropbox" tutorial again.

For those of you who made it to the end: I'm sorry. I made it as simple as I could. But it's just not very simple.