Unclear UX and annoying restriction for virtual and non-synced files

It might be the case that these are two issues, but they are so intertwined, so answers to one will involve the other anyway I assume, so I'm leaving it as one issue. If someone feels the need to seperate them, feel free to do so.

For my use of a cloud service on a specific client **I expect the following choices:**

a) file is on cloud and is synced completely for quick and also offline local availability
b) file is on cloud but shows up only virtually on client
c) file is locally on client but I do not want it to show up on or sync to the cloud
d) file is on cloud but I do not want to see it on this particular client at all, not even virtually

a) to d) are all taken care of, but the UX is not clear, and it seems you **cannot choose both b) for some files and d) for others,** which is a restriction that forces the user to choose between taking up a lot of space or facing the clutter of vast filetrees.

Today, in the desktop client command center you have checkboxes for d) only if you disable b) for all files. As a non-developer, I don't see why I have to enable or disable virtual files at all with a seperate menue item; why are they not permanently enabled, and I just tick checkboxes? (Or probably it would be radiobuttons) Also, this knowledge is not available in the manual yet, I needed to ask the community to learn it.

A menue item that changes name or dissapears is never a good UX in my oppinion (greying out is better, because you know you are being confirmed that you are looking in the right place).

**"Availability":** Here, in the three dots menue you have the menue item "Availability" that just dissappears if you have virtual files disabled.
* The options that it gives you, should not be menue items at all, but radiobuttons, since they are either-or.
* It should be enough that this item appears in the folder tree, you can rightclick the root folder for the whole account (or possibly a few root folders, if you have several connections).
* When virutal files are enabled, and you rightclick on a file in the command center to make it virtual, you have no indication that you have done it. In order to check, which files are virtual, you need to go to your file explorer and hope that you have the column visible to tell you, and then click through all the folderstructure to get an overview.

**"Enable virtual files ..."**
* As mentioned, it should not be something that needs to be enabled before it can be used.
* The three dots at the end of "Disable virtual file support ..." (Windows 10, client version 33.0.3) are okay, because clicking takes you to a dialogue box with info about what you are doing. What's the worst thing to happen: your harddrive fills up.
* That info says that the only advantage is, that selective sync is available again. Well, another advantage is that files don't take forever to open and hang your applications that cannot deal with that.
* The three dots at the end of "Enable virtual file support ... " are treaterous, they don't take you to any confirm dialogue box. Clicking the menue item is it. Your system lets go of files immediately (after a bit of lag actually). Now a user gets concerned, if things are still there, if anything gets messed up...

I have been handling .gitignore-files and the like, so I could use today's tool for c), a list editor, with some ease, but it still annoys me and I guess it repels a bunch of not so tech savvy users; also, stuffed away in the three dots menue it becomes a hidden feature. It is still good for editing patterns for power users, so that radiobuttons for individual files get ticked automatically in my proposal below.

**My proposal is this:**
* have three radiobuttons for each file, call it maybe "managed sync" or so;
* the default, when none are ticked, is a)
* first radiobutton ticked: file will sync virtually
* second radiobutton ticked: file will stay completely on cloud
* third radiobutton ticked: file will stay locally

I'm sure there are designers among the community who have smoother proposals for this, go ahead =) But the current way is not intuitive, and it lacks a feature, and it's not even documented.

> [!TIP]
> ### Help move this idea forward
> * Use the 👍 reaction to show support for this feature.
> * Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
> * Subscribe to receive notifications about status changes and new comments.
---

**Is your feature request related to a problem? Please describe.**

**Describe the solution you'd like**

**Describe alternatives you've considered**

**Additional context**