If I increase the scope to include children I would have to remove the Browse/Read rights, because they are not allowed to view the contents of the folder.

But this would prevent them from seeing the folder itself, without a bypass browse global privilege.

Why do they need rights to the children? They only need rights to the parent folder, they just need to be able to see this folder, Create Documents in this folder and Modify Contents of the folder (since I assume creating a document modifies the contents).

It has been a long time since I set this type of configuration up.  In LF 7 and previous, we always made a recycle folder where users could drop entries in but could not view anything inside.  It always needed to have 2 scopes to accomplish.  The first was for this entry only and gave them the ability to see the folder and create/modify entries.  The second was on the children to again grant the create/modify but not the view/browse.

If you try to add a document to the folder as the restricted user with just a scope of this entry only, and then look in the folder as the admin, you will see that the entry was created, but it has none of the metadata or pages.  This is where the child scope comes into play.  If they do not have rights to the child, they can not complete the create/move activity.

Ah this is getting me closer. With the double scope, read on this and Create/Modify on this+children I can create new documents. But I still can't move documents into the folder, I assumed that Create Documents includes move events since Moving must be considered an Addition or Modification.

Create Documents is the only option under Add, Modify Contents is the only option under Modify. Both are checked. Moving couldn't possibly be a Delete, Manage Security, or Records Management event. I must assume that Create Documents or Modify Contents allows moving a document into the folder.

I might need to jump on a var webinar for this, it seems overly complex. I wish there was just a "Add Documents" checkbox under the "Add" group.

This is very interesting.  When I drag and drop I get a move/copy error, but then refresh and the entry is no longer in the original location.  Then use admin to look in the destination location and the entry is there so it did get moved in spite of the displayed error.

Here are my settings:

The error my test user gets on drag and drop is:

I do not know why LF 10.4.1 is throwing the error, but that is how I have always done it in the past.