Greetings! Your understanding of how it should work is correct, so lets’s dig a little deeper and see why you are not observing the expected behavior.
First, typically when we define a “consumer” we are referring to multiple processes, microservices, or devices which are pulling messages from a queue. However, you are correct, that if a single application creates multiple flows it will also behave as multiple consumers.
Now, for a non-partitioned queue (non-exclusive queue with partition count of 0) there is little to no benenfit of creating multiple flows on a single session instance, and even in the case of partitioned queues, the only side effect of having multiple-flows to the same queue in a single process would be how many partitions are assigned.
The crux of your problem likely lies in how you are dispatching the messages to their worker threads after they are received. You mention that you “assigned them to separate threads/tasks”, but can you provide more clarity or code samples to show how you did that?
Note that all code which executes within your EventHandler<MessageEventArgs> messageEventHandler callback initially runs on the same dispatcher thread for all flows, so that in order to acheive parallel processing, it is necessary to push any received messages to their respective processing threads as fast as possible.