itman

Add option to realtime scanner to block obfuscated Powershell scripts. Option would be dependent upon Win 10 AMSI option enabled in the Eset GUI.
Justification
Microsoft added a like mitigation in the form of a Windows Defender Exploit Guard ASR mitigation effective with Win 10 1709. ASR mitigations are only effective if Windows Defender is enabled as the realtime scan engine.
Further justification is Eset's failure to detect malware in highly obfuscated PowerShell script in a Malware Research Group ad hoc test: https://www.mrg-effitas.com/research/current-state-of-malicious-powershell-script-blocking/

Add option to realtime scanner to block obfuscated Powershell scripts. Option would be dependent upon Win 10 AMSI option enabled in the Eset GUI.
Justification
Microsoft added a like mitigation in the form of a Windows Defender Exploit Guard ASR mitigation effective with Win 10 1709. ASR mitigations are only effective if Windows Defender is enabled as the realtime scan engine.
Further justification is Eset's failure to detect malware in highly obfuscated PowerShell script in a Malware Research Group ad hoc test: https://www.mrg-effitas.com/research/current-state-of-malicious-powershell-script-blocking/

Add a column showing PID number in the following logs after the noted existing log column headings:
1. HIPS - Application
2. Network - Source
This is necessary to properly identify the origin for multiple same process occurrences such as svchost.exe. 

It actually used to do this prior to ver. 11. I believe this has something to do with Microsoft's decree to AV vendors that they can't interfere with the boot process in Win 10 ver. 1709. I am actually surprised that Eset even processes an Ask HIPS use in ver. 11 and instead, just auto allows it. I know it is doing so because it will slightly delay your boot time; something I though wasn't supposed to happen on Win 10 ver. 1709.
Again it is a bit peculiar that the HIPS default action is allow. However, it always has been this way. To be honest, I seriously doubt Eset will change it to block mode.
A proper frame of reference for you is Eset first and foremost created the HIPS for its own internal use. As such, it really isn't designed to be user configurable other than to create a few exception rules. This is more so evident in the retail vers. of Eset. For example, Eset added file wildcard capability a while back for the Endpoint vers. but refuses to do so for the retail vers..

I explained this once to you. Eset has internal default rules and those rules take precedence to any user created rules.
Also if an alert response is not received within a short period of time, Eset will auto allow the action. This comes into play for example with any ask rule that might be triggered during the boot process. Those will be allowed by the time the PC initializes, the desktop appears, and finally the Eset GUI is started. 

Nvidia in their "infinite security wisdom" created two .bat scripts they dumped in C:\Windows directory. Their startup service can run these .bat scripts if errors are encountered in their software as recovery procedures. So basically, you have to allow svchost.exe to run cmd.exe. Not the most secure thing to do if malware creates a malicious service. Hence my recommendation that file wildcard support is needed.
There is also the issue of why the HIPS hasn't been updated to reflect Win 10's current ability to uniquely identify an individual svchost.exe service by process id. 

Yeah, I know about this.
Just be careful with GitHub software. Being open source, it can be hacked. One of the major sources of nasty backdoors has been GitHub software.

As far as anti-exec processing, there is a one built into Win 10 - native SmartScreen. I have tested with a couple of unknown reputation files and each time got an alert from it when they tried to run. Eset let the files run w/o issue. Neither file was malicious but I prefer an option to disallow execution in this instance.
The downside is native SmartScreen relies on "The Mark of the Web" remaining associated with the downloaded file. There are ways to "strip that off" of a download.

I did some of my own testing in regards to this business about the HIPS not detecting Farber activity. For starters, I set the HIPS to Interactive mode and then ran Farbar.
To begin with, Farbar will load and begin execution because you started it manually. However, the first attempt by Farbar to perform any activity the HIPS monitors for will cause an alert as shown by the below screen shot.
Now if you create a .bat script and run Farbar by execution of the script, you will receive a HIPS alert about the startup of Farbar. Likewise, malware doesn't magically run by itself. Something has to execute it. 

I have run Farbar in the past and Eset HIPS in Auto or Safe mode will not alert because its a safe app.
Are you saying that the HIPS in Interactive or Policy mode is not throwing an alert at Farber startup time?

You will need to show an example of an .exe that Eset HIPS did not detect running in Interactive mode. The only way I know that could occur is if you inadvertently created an allow rule while running in Training mode or by manual creation. 
One possibility for example is that an allow rule was created for a process to start another process. If the allow rule did not specifically state what process start up was allowed, then Eset will allow any child process startup from the parent process.