I wish I had time to come up with more concrete information (examples/code) in this post, but I don't have the time to work that stuff up. I did think it would be useful for people searching for solutions to this problem, so here it is in all its ambiguity.
I was playing with expression tree inspection and dynamic interpretation the other day, when I hit something that I was sure was a bug. I was inspecting an expression tree, identifying "branches" of interest, and generating lamdba expressions from them on the fly.
You might do this to break up an expression into separate units of execution to spread across multiple processors (a la PLINQ), or to replace parts of a tree requiring local execution before passing off to another layer to be transformed into another domain like SQL, or whatever. In any case, I was doing it.
I found that if the type of the expression was a value type, I could not create a lambda expression returning object from it, even though there is an inheritance relationship. You get a fairly straightforward, but perhaps surprising exception.
After some back and forth with the Linq team, I discovered that this was by design. In the case of value types, the boxing operation required to make an object must be represented by a unary convert expression. The solution is to wrap such expression trees with a call to Expression.Convert(expression, typeof(object)).