Would it be feasible to add a Pause Queue feature?

[Rongway]

I believe this was suggested before, and it comes down to, how do they fairly replace you in the queue? How do they justify someone being #1 being bumped back to #2 when you return?

By not even trying. See my example immediately before your post.

That's not something that should ever happen.

Pausing and unpausing queue should never change the numbers. The only two things that should change your position in queue are

A) The #1 person is served, and everyone advances.
B) Someone in the middle of the queue leaves, and everyone after them advances.

Paused people should advance with everyone else as normal, with the restriction that the paused people start piling up beginning at position #2. That is, nobody who is paused can advance to position #1. This also has the effect that if people ##2,3,4 are paused,
1) A paused #2 cannot advance to #1 when #1 is served because paused
2) A paused #3 cannot advance to #1 when #1 is served because paused, but also cannot advance to #2 because #2 is #2
3) A paused #4 cannot advance to #1 when #1 is served because paused, but also cannot advance to #2 or #3 because #2 and #3.

[JWag12787]

By not even trying. See my example immediately before your post.

That's not something that should ever happen.

Pausing and unpausing queue should never change the numbers. The only two things that should change your position in queue are

A) The #1 person is served, and everyone advances.
B) Someone in the middle of the queue leaves, and everyone after them advances.

Paused people should advance with everyone else as normal, with the restriction that the paused people start piling up beginning at position #2. That is, nobody who is paused can advance to position #1. This also has the effect that if people ##2,3,4 are paused,
1) A paused #2 cannot advance to #1 when #1 is served because paused
2) A paused #3 cannot advance to #1 when #1 is served because paused, but also cannot advance to #2 because #2 is #2
3) A paused #4 cannot advance to #1 when #1 is served because paused, but also cannot advance to #2 or #3 because #2 and #3.

So basically if I pause in #10, I pause in #10, and everyone advances around me?
Person in #11 jumps to #9 while #10 is paused?

[Rongway]

So basically if I pause in #10, I pause in #10, and everyone advances around me?
Person in #11 jumps to #9 while #10 is paused?

No.

Did you even look at the timeline diagram? Nobody starts skipping around you except to become #1 while you're paused. Everyone advances normally, including the paused people, except that paused people cannot advance to #1.

1    2    3    4    5    6    7    8    9   10   11   12
I    C    J    K    L    M    N    O    P    Q    R    S
    !!                            !!
    
[I is served.  C is paused, so holds at 2.  J skips ahead.
 O is paused but not on deck, so P does not skip them]
 
1    2    3    4    5    6    7    8    9   10   11   12
J    C    K    L    M    N    O    P    Q    R    S    T
    !!                       !!
    
[C unpauses queue]

1    2    3    4    5    6    7    8    9   10   11   12
J    C    K    L    M    N    O    P    Q    R    S    T
                             !!

[J is served]

1    2    3    4    5    6    7    8    9   10   11   12
C    K    L    M    N    O    P    Q    R    S    T    U
                        !!

From a programming standpoint, it would have to be something like:

2- You are automatically shuffled back in the queue whenever someone with your role is "behind you"

What? Why would you think that is necessary?

The coding concept is simple.

Pseudocode:

q.pop
i = 0
while q[i].ispaused
    ++i
remove q[i] and re-insert them at front of queue

Whenever the first person in the queue is served, skip anyone at the front of the queue who is paused. The first unpaused person becomes the front of the queue.

[Tohe-Spidhire]

What? Why would you think that is necessary?

<snip>

Whenever the first person in the queue is served, skip anyone at the front of the queue who is paused. The first unpaused person becomes the front of the queue.

No, it isn't. Queue position refers to the party that you are in, not individual player.

So if you're DPS with a party in queue position 1, but go afk, that means you get shuffled to other parties further back in the queue because you're giving up your spot to newly arrived DPS.

Did you think you were going to hold back an entire party of players due to your being afk? Nope, you're ejected from the party when someone better comes along, and in short order you are in the furthest-back party, making it equivalent to having dropped from the queue. Therefore, not worth coding.

[Rongway]

No, it isn't. Queue position refers to the party that you are in, not individual player.

This is not a relevant point to the mechanics I've described. #2 player in queue v player in #2 party makes no difference; just don't let anyone who is paused advance to #1.

[Tohe-Spidhire]

This is not a relevant point to the mechanics I've described. #2 player in queue v player in #2 party makes no difference; just don't let anyone who is paused advance to #1.

Long story short, you've oversimplified the party matching that takes place.

If queue-party#1 has everyone except a healer, and queue-party#2 has everyone except a tank, and then a tank shows up, which party do you suppose is going to start *immediately* ?

Regardless, an afk-dps on either of those teams gets shunted onto queue-party#3, which is shorthand for "end of the line." No point having fancy coding when the person should have dropped from the queue.

[Shurrikhan]

Long story short, you've oversimplified the party matching that takes place.

If queue-party#1 has everyone except a healer, and queue-party#2 has everyone except a tank, and then a tank shows up, which party do you suppose is going to start *immediately* ?

Regardless, an afk-dps on either of those teams gets shunted onto queue-party#3, which is shorthand for "end of the line." No point having fancy coding when the person should have dropped from the queue.

All queues numbers visible to a player are already role-specific. If I queue for a trial, healer RQ #1-2 are first party, 3 and 4 the second, etc., etc.

If I pause at position #3, #1 and #2 go in, #4 and #4 become the new #1 and #2, and I'm left waiting for a further party, just as I would have been before pausing.

If I'm healer #3 for a raid and pause, 1, 2, 4, 5, 6, and 7 enter; I remain at queue position 3. I will still join the next raid to pop from the time I unpause (or maximum pause duration expires, etc.). Depending on bottle-necks among other roles, that may be a good 15 minutes later than had I remained at my seat until it popped and I could enter, but if returning to my desk within 45 seconds were possible, I wouldn't have hit pause and taken that risk over the chance of losing my queue entirely. I have substituted a risk of being pushed back to position #21 or so, the true end of the line, with the risk of the queue popping (while I'm unable to respond) to it, thus skipping an entry I could (not) have otherwise taken.

Bottlenecks within a particular role can push the others to maximum effective queue positions well beyond just the next-next entry. I would guess that if we only ever had nearly ideal proportions (i.e. only a run's worth of the least relatively populous role short of the most populous role's runs'-worth of players) queuing for a duty, you would be right, since the difference between position # (In for next entry) and # (In for the entry after next) would be the difference between the front of the line and the end of the line. But that's often not the case, so I'm not sure it's quite so clear-cut.

That said, it may indeed not be worth the trouble to code for a doubly niche benefit. That's largely why my original question was phrased as such, to discuss whether it'd first even be feasible, secondly--worthwhile, and only finally--attractive.

NOTE: I may still be misunderstanding what you've said here. Or, more particularly, I'm not sure I believe that, say, a solo-queued individual player is bound automatically to a particular party until the time that there are sufficient numbers of each role for a party to be matched, as that goes against what I've heard from people who've analyzed this in the past. Any further links or data would be appreciated.