The fulltext operator "contains none of these words" is not working

Which filter are you using? One for a specific field or the "Search: Fulltext search" filter? In the latter case, what is your setting for "Use as"?

OK, I was able to reproduce the problem. Thanks a lot for reporting it!
I'll see whether I can come up with a patch to fix this (and add some tests – I'm amazed we aren't catching that right now).

Wow, this sent me on quite a journey … Turns out there were related bugs in both Search API Views (#2128001: Fix logic for "contains none of these words" fulltext operator) and Search API Solr Search! Also, finding and fixing the bug in this module wasn't that easy either (it rarely is, considering the complexity of our queries). But I think I managed it – attached are a patch with some additional tests (which should fail) and one that combines these tests with the fix I implemented.

Please see whether using this patch (and the one in the Search API issue, unless you want "contains not all of these words") fixes the problem for you, too! And again, thanks for reporting!

I have no idea why the patches fail to apply. I'm just re-attaching them now, let's see whether that helps.

For testing it would be great if you could do the following: First just apply the "combined" patch in this issue and see whether the filter is now working correctly (excluding for one word, not throwing an exception for multiple words) – but bear in mind that it is at that point a "contains not all of these words" filter, so you'll also see results that only have one of two entered keywords. (Optionally, also run the "Search API Database Search" tests to see if they now/still pass.)
Then, go to the Search API issue, apply the patch from there and see whether that correctly makes the filter exclude items that have any of the words when entering multiple search terms (instead of only excluding those that have all of them).
Then report back on your findings in both issues (or just in this one, I'll read it anyways ;)).

Thanks a lot for testing, Gilsberty, and providing such great feedback! Good to hear the patches worked well for you.
There's really nothing more you can or need to do here – I'll just wait a few more days (as is my custom, so other people can chime in if they want) and then commit both patches.

(The testbot fails due to its idiotic behavior of using the version supplied in the issue – changing that to the dev version will hopefully fix this.)

7: 2127001-7--negated_fulltext_keys--tests_only.patch queued for re-testing.

7: 2127001-7--negated_fulltext_keys--combined.patch queued for re-testing.

No need, we just ignore that one. It's a bit annoying the test bot can't figure this out by itself, but still.
As said, if no-one else objects, I'll commit this in the next days. Thanks again!

Committed.
Thanks a lot for testing so thoroughly! This is really a great help for me.

Of course this should be fixed, but this seems to be an entirely different problem, so please create a new issue for it.
If you can find the complete query, that would be helpful. The problem seems to be the "Node access" data alteration (which of course doesn't fire for admins), or rather the DB backend not creating the right query for it.
It would be great if you could test this with both the 1.0 and the dev version of this module, to see whether the patch in this issue really introduced the problem.

It wouldn't have been necessary to re-open, as long as it's not closed I'll still see it. Just didn't have the time to check my issues in the last days.

Anyways, please create a new issue, and describe your exact steps. I'm pretty sure this is an old issue that was just hidden before.
Also, I could not reproduce this with MySQL, so maybe that's even a bug in the Postgres database layer. For MySQL, when searching with node access and "contains none of these words: macto", the following query is created:

SELECT DISTINCT t.item_id AS item_id, '1' AS score
FROM 
{search_api_db_default_node_index} t
LEFT OUTER JOIN {search_api_db_default_node_index_search_api_access_node} t_2 ON t.item_id = t_2.item_id
WHERE  (t.item_id NOT IN  (SELECT t.item_id AS item_id
FROM 
{search_api_db_default_node_index_search_api_viewed} t
WHERE  (word = 'macto') )) AND(( (t.status = '1') OR (t.author = '12') )AND( (t_2.value = 'node_access_all:0') OR (t_2.value = 'node_access__all') ))

As you see, the status is correctly filtered for "1", not for the fulltext keyword. It might be that the Postgres database integration misplaces an argument there. Or I'm using it wrong and the MySQL layer is just constructed in a way which hides this problem.
In any case, I have seen where the problem is, but the complete query would still be useful. But I admit it's not easy to get to that, especially if you're no developer.
If you have Devel installed, put dpq($db_query); below the $time_processing_done = microtime(TRUE); line in service.inc, give a non-admin role (so node access will fire) the "Access developer information" permission and then trigger the bug with a user of that role.