A general question:

Patches that fulfill a condition are redirected to a apple procedure and if the result of that apple procedure != 1 then the patches that had varA = 1 are redirected to a plum procedure, the one that had varA = 2 are redirected to a berries procedure.

Is it more standard to :

use the same apple procedure for both patches with [varA] OR [varB] and redirected with the result of apple procedure

to banana
ask patches with [varA = 1] [apple]
ask patches with [varA = 2] [apple]
end

to apple
***some procedures and calculation ***
if patch (varA = 1) [
ifelse (result = 1) [pear] [plum] 
]
if patch (varB = 2) [
ifelse (result = 1) [pear] [berries]
]

end 

OR*********************************

copy-paste the apple procedure into another procedure (papaya) that will be used only for patches with [varA = 2]

to banana
    ask patches with [varA = 1] [apple]
    ask patches with [varA = 2] [papaya]
    end
    
    to apple
    ***some procedures and calculation ***
    
    ifelse (result = 1) [pear] [plum]
    
    end 

   to papaya
   ***some procedures and calculation ***
   ifelse (result = 1) [pear] [berries] 
   end

?
Thanks for your time and insight

>Solution :

problem ———————————
The first option is impossible: patches doesn’t know what patch it belongs to and thus doesn’t know whether it is a varA type or varB type. So regardless of whether it is "more standard" or not, your second option is your only option. However, there is another option that accounts for the case when you wrongly call the grpB procedure with grpA patches and the grpA procedure with grpB patches.
Solution ———————————
The easiest way to make your code future-proof is to include checks for compatibility right in the */apple procedures. It might be a little bit more verbose but it makes your code more user-friendly and much less likely to crash or produce unintended results. Below is a minorly changed version of your code that we can test.

  once
  reset-ticks
  ask patches [
    ifelse pcolor = 2 [
      ifelse varA = 1 and varB = "grpA" or varB = "grpB" [
        set pcolor green
        apple  ;;run the applicationf for grpA
      ] [
        set pcolor orange   
        show reduce [item 0 ? kernel density ( max-pxcor + random 10 - 25) ( max-pycor + random 10 - 25) 1 0.5 ] 
      ]

      ifelse varA = 2 and varB = "grpC" [
        set pcolor brown
        plum  ;;run the application for grpB
      ] [
        set pcolor red
        show reduce [item 0 ? kernel density ( max-pxcor + 10 + random 10 - 25) ( max-pycor + 10 +  random 10 - 25) 1 0.5 ] 
      ]
    ]
  ]
end

I won’t explain this (or any of the other answers to your other questions) but you can ask me if you would like, or read the documentation on patches, if/else/reduce, lput and other terms.
want more———————–
I also think that putting grpA and grpB into a list and just using table, using show and count, using turtles all make for very easy to read and pretty code (if you want it) ***

  if pcolor = 1 or member? varA food and member? varB food [apple]

to apple
  let result (random-int 2)
  if result = 0 [turtles-at pxcor pcyor]
end

Again, don’t ask me if you don’t understand anything just read prims and doc. If you’re trying to solve a real-world problem, you might want to consider this last one since turtles would very easily follow your agents and put food down; in fact if you modified them so that berries and apples require less energy than keeping the agent alive, the agent can wander around the map till satiated and only eat what it needs. Also, you’ll come across problems when coding your lumps that are much more specific that general coding key terms, so don’t be afraid to ask (your question is really to vague for an answer more extensive than mine personally, and I don’t wish to read all of your past posts, so take my revisions not as answers but as advice).
Side-note —————————————————————–
To make your code future proof, it needs to be compatible with what ever application comes after it, whether is processing a report or producing another simulation or producing different files or whatever. So the main idea is to include compatibility checks that are usually present in user software including compatibility if-else-statement branches, try…catch… blocks, right-errors, screen opens, dialogs, etc..; just make it easy for whatever user you are almost sure will want to use this part of the code in future projects: developing is no better than coding; you’re actually making a publishing so don’t be afraid to put your own stuff into it.