We tracked the unwanted behaviour to GetItemDiscountProcessorBase.Evaluate so more promotion types might be affected and not just SpendAmountGetItemDiscount promotions.

I might be missing something here, but if I understand you correctly, then the behavior you mentioned is intentional, and actually correct. In this case Y is considered as the "conditions", and because the price is > 190 and < 200, which statisfies the condition for the promotion (total >= 200), the promotion is "almost fullfiled". 

The problem you see is how you treat the RewardDescription returned. It does not say " promotion is partially fulfilled for Y". It says "Y partifully fullfils the promotion". 

But by that logic Quan wouldn't any item Y with a price >= 200 be counted as fulfilled but it isn't fulfilled or even partially fulfilled?

How can a better match of the conditions result in a lesser fulfillment completion?

It fulfills/partly fulfills the condition(s), that does not mean it is getting the discount :) 

No it doesn't.

I know that it doesn't get the discount but if it costs more than 200 IPromotionEngine.Evaluate(...., RequestFulfillmentStatus.Fulfilled | RequestFulfillmentStatus.PartiallyFulfilled) will yield an empty result.

So if it costs >=190 and <200 we get FulfillmentStatus.PartiallyFulfilled but if it costs >=200 we get FulfillmentStatus.NotFulfilled. Do you understand my confusion?

OK that part I can understand. So if the item is <200 then the status is PartiallyFulfilled (correct), but if it is > 200, then the status is NotFulfilled (incorrect, which should have been Fulfilled), right?

I am looking at the code now and I think I understand the problem. The promotion engine uses PromotionApplicator to check if a a promotion can be applied, and if it is (Fulfilled), it tries to apply the promotion, which, in this case, fail, because the item(s) qualify for the condition(s) are not the item receiving the discount.

Interesting. We will look into this. Can you post your test code here so we can use it to verify once we fix the bug? 

That is correct according to your logic atleast then I can understand it, our customer wants it the other way around, but that is because they have seen the X set as part of the condition. I fully understand that you can't oblige them there as it wouldn't make for a solution that fits everyone, I will inquire the customer about why they do it like this and see what solution I can give them.

No test code to post im afraid, we have been setting up the scenario in admin mode and just run the evaluate method in the test to reproduce the issue.

We haven't written code for setting up the scenario. :P

FYI the customer will try and make their marketers use "Buy Products for Discount on All Selections" instead but they are sceptical as they had limited success with getting the marketing department to follow instructions before (one thing mentioned was difficulty getting them to prioritize entry level discounts higher than order level discounts).

If you do return Fulfilled even if Y isn't part of X you might want to pair it with NoMoneySaved so it could be filtered out by those who wants to ignore them. Also maybe pair PartiallyFulfilled with NoMoneySaved for clarity.

I created bug COM-6195 so we can look into it. Thanks.

What are you guys doing in this forum??

"Discuss error messages and Episerver CMS behaviors and features."

You've fallen into the CMS trap!

It's a hidden gem. 

I can move this to Commerce forum instead