Every developer eventually has to do second or third tier technical support. It's usually well after you've delivered a product and some important customer has a show stopper. The front-line people have thrown their hands up and turfed it to you.
They key is to learn to respond to customers in a way which makes them feel that you are really are looking into their problem and trying to make the products better, not just reading form a script of slap-dash workarounds. It's not magic.
The essential bit is steps 4 and 5. That let's them know you have given them a priority response, but that configuration management and quality control issues keep their patch "special" until we can make a real release. That gets you off the hook for supporting their patched version forever. It also gives you a rationale for taking the time needed to deliver an official fix. Most people are comfortable if you explain that you want to deliver a quality solution rather than a fast one. The important thing is to give them sensible reasons for why you are doing things.
When the next stable release comes out you can tell them about the update and put the problem of evaluating and accepting it on their heads.
Non-reproducibility is a real pain. But I think most things are if you dig deep enough. I also think the customers stay happy if you keep giving them quick feedback, even if it is not good news.
Customer: yada, yada, SEGFAULT. Support: We tried what you said, but can't reproduce it. Can you send a sample? C: ....example.tar... S: I got the example and unpacked it. I will be able to look at this this afternoon.
-- The response is important. I just got points for being prompt, yet I bought myself the time I need to examine what they sent before responding again.
S: I got your example to build, but can't reproduce the problem I had had to change these things to fit our environment. Can you tell me more about your Oracle setup? Can you give me the exact schema definition for those tables you use? Can you send me some sample data? ....