Yes, there have been ongoing problems with each 6scan version that is released. the problem is that 6scan is trying to use the same space/position in the root .htaccess file that BPS is using instead of 6scan creating its own allocated space/position in the root .htaccess file.
BPS is the dominant and primary plugin when it comes to .htaccess website security protection so what i have considered doing is creating a coding check that will check if 6scan is installed on a website and then move that 6scan coding where it should be in the root .htaccess file so that it does not interfere with BPS.
The problem with doing this is that 6scan keeps changing the coding that breaks the BPS root .htaccess checks in each new version of 6scan that they release. So this means that i would have to keep changing my checking coding to fix the new coding issues in each new version of 6scan that is released.
That is obviously not a good approach and the better approach is since BPS .htaccess code has always had and will always have consistent identifiers (BEGIN, END) in the code/root .htaccess file then 6scan should be using these consistent BPS identifiers to position/add their 6scan .htaccess code in the root .htaccess file.
The solution would actually be very simple for 6scan to do: use file_get_contents, do a preg_match, do a str_replace or preg_replace and add their .htaccess code based on the consistent BPS indentifiers using either file_put_contents or fwrite.
I will test the newest release of 6scan and find out what the problem is this time. Thanks.