Probably the easiest way to find relevant papers is to do reverse-citation on Cifuente's work ("Reverse Compilation Techniques" and "Structuring Decompiled Graphs").
The newest paper I've found (I was specifically looking at control flow graph structuring, which ends up being nasty to search for) is " rel="nofollow">https://net.cs.uni-bonn.de/fileadmin/ag/martini/Staff/yakdan....
Edward Schwartz's PhD thesis (" rel="nofollow">https://users.ece.cmu.edu/~ejschwar/papers/arthesis14.pdf>) covers in detail the Phoenix decompiler, which is another good jumping-off point.
All of the papers I've mentioned can be found in citations from those two sources.
As for the state-of-the-art, the basic disassembly algorithm has been well-known for a while: recursive disassembly, which is the sort of obvious algorithm you'd think of yourself if left to your own devices. The practical answer is generally "use IDA," because indirect control flow boils down to "know every single pattern that compilers generate," and IDA already knows every single pattern. Structuring control flow graphs is more or less complete in the same sense as parsing is, which is to say that we know a few different ways to do it which all suck in their all special way, but you're not going to find fertile ground to do new things, as the existing solutions are generally good enough.
The real hard part of decompilation remaining, then, is variable and type recovery. We sort of know how to do this if you assume structs, unions, and arrays don't exist (which is to say, it's more or less solved if you were to try this on CIL or JVM bytecode), but those are a massive stumbling block in native executable decompilation. I rather suspect this is going to remain unsolved until we get a good pointer and dataflow analysis on binaries that can handle integer/pointer duality and type unsafety, which puts it at least a decade away in my estimation.