Hypothetical scenario 1:
There is a queue on which 1 task is blocked waiting for data to arrive. Data arrives and the task unblocks. The task was just wanting to peek the data (not remove it) so takes a copy of the data and leaves the queue peek function. Now presumably it will perform some action, then later go back to the queue again where it will immediately find the data it just peeked. I think this behaviour is logical and ok, and is how the GenQTest.c demo tasks work.
Hypothetical scenario 2:
There is a queue on which 2 tasks are blocked waiting for data to arrive. Both tasks are the same priority. Data arrives and unblocks one of the tasks, this task was just peeking so takes a copy of the data and leaves. Now what should happen? There is another task blocked on the queue waiting for data, and there is already data in the queue - should this second task be unblocked after the first task has peeked the data? What would be the logical thing to do, or how would you expect this scenario to work?
Hypothetical scenario 3:
Same as 2, but this time the two tasks that are blocked on the queue are of different priority. The higher priority task wakes and peeks the data - should the second task then be unblocked because there is data in the queue that was not removed? The second task is of lower priority so will not execute until the first task blocks again (it is ok if the first task removes the data before the second task executes, FreeRTOS.org already handles this situation).
Provided the behaviour is documented, does it matter which implementation is chosen (wake the second task, not wake the second task)?
Maybe it should be a compile time option - but this would add complexity and more preprocessor macros, plus more code to test.
Maybe there should be a rule that tasks can not block on a queue when they are just peeking?