This situation subverts BGP's basic loop prevention mechanism. If the
/20 is ever deaggragated into more specifics, a forwarding loop may result.
If you want to put rounds in the chamber before pointing the muzzle at your temple, you're free to do so. However, some of us would prefer to stand a long way away.
It seems to me that this is only true if there is ever a possibility of one of your next-hops believing the route to the destination is back through you - or perhaps if the upstream has no route at all to the destination. In the case of most non-tier-1 networks, any packet destined for anywhere outside my own ASN (and customer ASNs if you have BGP customers - which I do not) can be handed to any upstream transit provider without fear of looping. So, the device injecting the traffic engineering route needs to be smart enough to never inject a route that matches an announcement of you or your customers. Beyond that, looping (should) never happen simply by definition of the transit/customer relationship. So, it subverts BGP's loop detection - but the transit/customer relationship (hopefully combined with appropriate announcement filtering) avoids the issue. Of course, if you leak one transit provider to another, and that gets accepted, you might loop due to your traffic engineering routes - but at that point you've got plenty of problems anyway.