How to interact with a module from a different module

Why do you need to have both custom modules, can't you build the pricing rules into one single module and an appropriate logic hook instead?

Would be easier to bug fix and maintain in future as well.

I can not, because the business intends to sell it as separate optional stuff. Customer can either buy only module "A", or module "B", or both "A+B", or neither

You can still sell based on the enabled functionality/options all in same A+B single module

Erm.. even if that would be the case read above. It is not sufficient to detect if module "A" exists. I need to detect if module "A" was actually applied to the product that I am about to add to the Quote.

Maybe I missed something, but if you only have module 'A' then doesn't that make it simpler than checking if both A and/or B exist and all the other additional checks to see if one or the other has been applied?

You missed a bit from my explanation or I am not clear enough. This question is about the "A+B" situation, when both exists but they are not equal. A touches files in custom//modules/Quotes/clients/base/views and module B touches files in custom....Products/clients/base/fields. But both A and B are actually used in quotes module, as you have seen my screenshot. A and B are not equal. If "A" was used than B should not apply his own magic, to avoid double discounting. (in reality both modules are discounts, one is quantity based (our "B") and one is simply a list of alternatives (think VIP, Member, Gold, Platina, etc)

You missed a bit from my explanation or I am not clear enough. This question is about the "A+B" situation, when both exists but they are not equal. A touches files in custom//modules/Quotes/clients/base/views and module B touches files in custom....Products/clients/base/fields. But both A and B are actually used in quotes module, as you have seen my screenshot. A and B are not equal. If "A" was used than B should not apply his own magic, to avoid double discounting. (in reality both modules are discounts, one is quantity based (our "B") and one is simply a list of alternatives (think VIP, Member, Gold, Platina, etc)

Yeah, I got that, maybe I wasn't clear that my suggestion is to combine A+B to only use ONE module/solution for all you pricing requirements.

Then include ability to switch on/off not required or unsold features 

Once the ProductTemplates relate field fetches the Item from Catalog + Priceline (if applicable) then I believe there is a custom endpoint behind it. If so, you can update in the target QLI either the Priceline ID or a boolean which may be evaluated by the custom_pricing button so it can decice whether to run or not.

Cheers