I know view only wallets only let you see incoming transactions, but have there been any proposals as of 2018-05 to create a view only wallet that also lets you see outgoing transactions?
View-only wallets can see the outgoing transfers if key images are imported.
In a regular wallet, the private spend key creates a key image for any output owned by the wallet. This happens during the scan. The key image will be there waiting when the time comes to spend an output. At the time of preparing a transaction, the key image will be included, and the private spend key will also have to sign the transaction.
If key images are imported into a view-only wallet, the wallet will be able to find out from the daemon whether the key image is in the blockchain's list of key images. If the key image is there, then the wallet knows that the corresponding output has been spent.
I said it already, but note that the key images alone do not allow the view-only wallet to sign a transaction, so there is no risk of turning a view-only wallet into a hot wallet by importing key images.
To address your question more directly, there have been informal proposals for view-only wallets that have a built-in ability to see outgoing transactions, but they would require further modifications to Cryptonote, and they would not come without trade-offs. Perhaps someone else will chime in with greater detail on those trade-offs.
There is at least one such proposal, by TheKing01: https://www.reddit.com/r/Monero/comments/51i0n7/solved_it_hopefully_heres_how_we_can_make_the/
From that post:
Currently, when a transaction is made, as described on page 5 of the cryptonote white paper, the sender creates a random r and includes R = rG in the transaction. They also calculate a one time address, P=H(rA)G+B (where A=aG is the public spend part, and B=b*G is the public view part, and A|B is the address, and H is a hash function). I will rewrite this as P_s = H_1(rA)G+B. The sender will also included P_v = H_2(rA)G+A in the transaction, where H_2 is a hash function different from H_1 (it could, for example, be H_2(x)=H(H(x)), or H(0|x)). The reason H_1 and H_2 must be different is because otherwise P_s - P_v = B-A, which would trivially connect the transaction to the address.
The private keys for P_s and P_v are H_1(aR)+b and H_2(aR)+a respectively. Both can be calculated by the sender, but only the private key of P_v can be seen by the viewer.
Now to spend, the spender uses a MLSAG (which is described in MRL-0005), using (P_s, P_v) as a key vector. In particular, this means proofs the spender controls the private keys to corresponding P_s and P_v (which is important, since if they where different, that would cause major problems). It also creates key images for both keys: p_sH(P_s) and p_vH(P_v).
This key images don't only prevent double spending, but also allow the auditor to identify the transaction, since they have p_v. Therefore, no interaction is required; the auditor can see right on the block chain.
This should also be compatible with RingCT, since it also uses MLSAG, and it seems it could be modified with the above. It could even be included with RingCT, if we deemed it input.
p_sH(P_s) is redundant, since p_vH(P_v) prevents double spending and allows both the sender and the receiver to identify the transaction, but must be included to verify the MLSAG signature. A minor tweak to MLSAG can probably be done to not include p_s*H(P_s) though, saving space.
A sender including both P_s and P_v in a transaction would take extra space. To save on this space, P=H(P_s|P_v) could be included instead. Both the spender and the viewer can check is a transaction is addressed to them by checking if P=H(H_1(aR)G+B|H_2(aR)G+A). Both P_s and P_v need to be included in outgoing transactions though. When they are, it is trivial for nodes to check if H(P_s|P_v) is an output.