Q:

Publishing projects fails because of locked files

The solution I am currently working on, the team made the decision to use habitats way of publishing projects in our solutions via gulp tasks. We are finding out however that periodically when we try to publish to our web-root the files are locked and the whole publish process fails because of this. 
This causes two problems:-

Unclean half publishes
Time wasted, waiting to deploy again

So I want to know a few things:-

Is there a way to avoid the half publishes or a way to reverse what we have tried to publish?
Can we get round this intermittent issue of files being locked by a process?
Is this a fix we can do modifying our gulp scripts if not then any other guidance is appreciated.

Example lock
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Deploy\Microsoft.Web.Publishing.Deploy.FileSystem.targets(96,5): 
error : Copying file obj\Debug\Package\PackageTmp\bin\roslyn\csc.exe to C:\inetpub\wwwroot\WebSite.local\Website\bin\roslyn\csc.exe failed. 
The process cannot access the file 'C:\inetpub\wwwroot\WebSite.local\Website\bin\roslyn\csc.exe' because it is being used by another process. Error!

A:

As asked in comments above; normally /bin files should not be locked for any particular reason (other than when the site is just starting up) - so I'm not entirely sure what's going on.
I can help you on the intermittent part of your question however; I would just flip the app pool before starting the file publish task.
appcmd recycle apppool /apppool.name
There are a few NPM modules that can execute this for you. One would be gulp-run. It would look something like this:
gulp.task('reset-apppool', function() {
  return run('appcmd recycle apppool /apppool.name').exec()
    .pipe(gulp.dest('output'));
});

EDIT: Updated to include after additional information was added to original question
The fact that Roslyn is the locked file, this may actually lead to more of an answer. I suspect Roslyn.exe is busy compiling all of the SPEAK views in your solution (or even just your own .cshtml files) and that is why it is locked at the time you deploy again.
I sourced some information from this answer: https://stackoverflow.com/a/38309167/81631
And I assume you have the DotNetCompilerPlatform package referenced in your project?
If this is all true, there are two things I would try next.

Follow the recommendation in the answer - even if I am not entirely sure of the full ramifications of it.

To resolve this issue, simply uncheck the "Allow precompiled site to
  be updatable" option in your publish profile settings. This should
  pre-compile your views and allow your C# 6.0 (Latest version of Roslyn
  Compiler) to run like a champ.

If this doesn't help; possibly your site is spending too much time on recompiling over and over. I recommend adding the optimizeCompilations attribute to your web.config <compilation> element.

<compilation debug="true" optimizeCompilations="true">

See if that makes the problem go away.

A:

I used Habitat build chain some time ago and had similar issues.
I am not sure if it solve 100% of our problems but here is what I learned.
Locked items
Check your references. Exclude unnecessary DLLs from publishing.

Unnecessary dlls are those dlls which are present in Sitecore Website/bin directory by default. You should avoid copying Sitecore.Kernel.dll, Sitecore.Client.dll and so on.

Steps:

Find potentially broken projects
Identify unnecessary referenced dll in your project
Right click on it and select Properties
Set Copy Local property to False

I remember that those unnecessary referenced caused some issues while running Publish Projects .
Unclean half publishes:
One of the reason why your files might be still unpublished even if you run publish and everything seems to be fine is Local.pubxml.user file.
Navigate to your project folder: c:\proj\src\Foundation\P1\code\Properties\PublishProfiles\.
and remove it (there are two files Local.pubxml, Local.pubxml.user - first one is fine, second is a temporary file.)
Hope it solve at least one of your problems.

