Some precedent here is that built-in derives are executed before custom derives.
One question about approach 2 is how context would be handled? Proc macros don’t have any context about the crate/module they’re being expanded in, but this would be needed to perform expansion. So this API would have to get the context from some TLS or whatever. And if that’s considered acceptable, why not let the proc macros get some more of that context themselves? 
Are you talking about expanding macros anywhere in custom derive input, or just in attributes? Isn’t this also tied in with the debates about eager expansion (this is morally equivalent to eager expansion as far as I can tell) and macros in attributes? I see there was a thread about the latter, but it somehow got turned into the above linked RFC for an eager expansion API for proc macros, which doesn’t solve the original issue (e.g. #[path=concat!(...)], #[doc=stringify!(...)]) at all.