differences exist between two processes of a single Routing protocol?

[Shenshen]

It is my understanding that a process is a specific-instance of a routing protocol. The process-id is a symbolic representation of a unique instance of that RP within a router.

If that's the case, what configurable/non-configurable changes can make one process stand apart from another? (Why would there a need for many RP processes?)

[MHM Cisco World]

I see one design need EIGRP BUT, if we config one Process EIGRP then loop or suboptimal path is  happen between different Routers so we need two EIGRP process to isolate Here the trick 
Isolate the UPDATE go from one Router to other through this router "this router have both process and have route from both process in it routing table" and then config filter to filter which UPDATE go from this Router to other Router.
when can config filter with distribute from one process to other.

[Richard Burts]

I believe that there are at least 2 questions in the original post. One is "what changes can make one process stand apart from another" I am not entirely sure what this is really asking, but believe that there are several things that might be part of the answer:

- you might set the AD for one process higher than the other if both processes might have the same prefix in their table and you want to establish a primary/secondary relationship.

- if you were running EIGRP and for some reason you wanted to have automatic summarization enabled for some neighbors and not enabled for other neighbors, then you would run 2 EIGRP processes, one enabling auto summarization and the other not.

- if you run several processes of the same protocol each would learn its set of routes but would not share its routes with the other process of the same protocol.

The second question is "Why would there a need for many RP processes?" I have sort of answered that in my previous explanation. But let me describe a particular situation which addresses this part of the question. I worked with a customer who provided a service to multiple hospitals. They needed network communication with each client hospital. The customer needed their routing protocol to learn the subnets of each client hospital (so that staff at the client hospital could access the service running on my customer's network. But they needed the client hospital not to see the subnets of other hospitals. The solution was to run multiple instances of OSPF. One OSPF process for each client hospital. With this implementation my customer saw routes from every client hospital but the client hospital only saw routes from my customer (did not see any other client hospital routes).

[Joseph W. Doherty]

"if you run several processes of the same protocol each would learn its set of routes but would not share its routes with the other process of the same protocol."

At least with OSPF, very much true, very similar to running two different IGMPs on the same router.

BTW, a couple of decades ago, I setup two OSPF processes on a router that had a "foot" into two different DMZ segments.  Since you had to use redistribution, between the two OSPF processes, by default, each OSPF segment was "blind" to all the other routes in the other OSPF segment, unless you explicitly redistributed them.  To get the most out of this, I recall (?) those segments, did not use a default route "pointing" to the aforementioned router.  I.e. also by default, any traffic, to an unknown network, would be dropped.

Again, this was decades ago.  Today, what @Richard Burts described, or perhaps what I did, might be done via VRFs.