Errr... TCP ACKs are not packets, they're a flag in the TCP header. TCP ACKs can not be "stuck" in the TCP queue, simply because they're added to the first data packet being sent.
TCP supports urgent data. Urgent data is used to signal the receiver that some important message is part of the data stream and that it should be processed as soon as possible. To send urgent data specify the MSG_OOB option to send(2). When urgent data is received, the kernel sends a SIGURG signal to the process or process group that has been set as the socket "owner" using the SIOCSPGRP or FIOSETOWN ioctls (or the POSIX.1-2001-specified fcntl(2) F_SETOWN operation). When the SO_OOBINLINE socket option is enabled, urgent data is put into the normal data stream (a program can test for its location using the SIOCATMARK ioctl described below), otherwise it can be only received when the MSG_OOB flag is set for recv(2) or recvmsg(2).
Search for "urgent pointer" in TCP for further explanation.
Now, does ns-3's TCP support urgent data? Honestly, I don't think so (perhaps nobody asked for it). Moreover, it's a feature that is not used very often (but it's used in telnet and ssh).
Solution? Use two different sockets. Or don't fill the TCP send buffer.