I´m running out of work! Why ???

I had a look at the scheduler logs for the most recent contact (at the time of starting this reply) and I saw a horrifying mess :-).  To me, it looks like the scheduler is having great difficulty in handling the ever increasing number of runs, sub-runs, sub-sub-runs, extensions to runs, switch-backs to earlier runs, etc, etc.  It looks like it can't decide which large data files are available or not, have tasks or not, have been marked for deletion or not, etc.  There are lots and lots of [debug] lines scattered through the whole deal which seems to imply that the Devs are experimenting with the code and trying to sort out how and why the scheduler is making (or not as the case may be) decisions about the sending of work.

Maybe you are just a victim of a scheduler that can't work out what to send to you.  Maybe there is actually a shortage of new work (primary tasks).  The two extra tasks you mentioned receiving show up in your list of tasks with an _2 extension.  They are resends - not new primary tasks.  One of those shows as 'in progress' and the other shows as 'aborted'.  Did you actually abort it?  Perhaps it was aborted by the system somehow?  Perhaps one of the original tasks got returned late so that the resend was no longer needed?

If you continue to request work, by the luck of the draw you may get further resends as they become available.  You don't have to wait 30min to make a further request.  You can override that delay by clicking 'update'.  There are likely to be resends available if you keep trying.

The other action you could take would be to allow some gamma-ray pulsar tasks until whatever is ailing the supply of GW tasks gets fixed.

This is NOT a task.  It is a single large data file (one of many) required for the processing of a task.  There is no such thing as a task file.  A task only exists as a group of parameters that are stored in your state file (client_state.xml).  Those parameters are received in the payload of a scheduler reply and are immediately inserted by the client into the state file and not as any separate task file.  When those parameters are 'used' to create various 'result' output files, they will be removed from the state file automatically on the successful transfer of the results back to the server.

That is a normal response and in now way is it contradictory.  Project files are NOT tasks.  They are simply all the ancillary files deemed to be necessary for the project to run correctly.   They are things listed in the state file which is how the client knows exactly what you should have and what to complain about, or download afresh, if missing.  Many have no direct bearing on crunching - things like image files, slideshows, etc.  The important ones are things like large data files (you will likely have many of these if you have been crunching for a while), application files and various other bits and pieces - but NOT files representing tasks.  When you see that single line with no other complaints, you know that all is normal as far as the client end is concerned.  Since project files are not tasks, they will never be listed on the tasks tab of BOINC manager.

There is no inconsistency.  If there were, you would see specific messages about the problem.  What you are seeing is what seems to be a scheduler problem or perhaps a genuine lack of new work.  I don't know the true situation as I'm not running any GW CPU work.  Given the time of year, there may be a delay in providing new work if such a shortage does exist.  Your best bet (until things change) is to try more aggressively for resends or (a lot easier) allow some gamma-ray pulsar tasks until the shortage is fixed.

Just to inform:

I received the last WU GW 2.07 _0 or _1 on 23. Dec. at aprrox. hour 19 UTC.

Since then, dead silence.

AFAIK O2MDF is the GPU app.  O2MD1 is the CPU one - it only has a handful of tasks to send.  I have all the GW apps selected in preferences except the GPU one, and in the last 5 days it appears only one of my 3 desktops has received any GW-CPU tasks.  

I run deep local work caches so even my fastest pair of boxes still have a decent amount of work left; but will run dry sometime next week if no one comes in who can address whatever the problem is.