There are two features that medusa needs to better support libraries:

1. medusa does not support external libraries. External libraries are unique since you must first deploy the library, resolve their addresses, update the contract bytecode with those addresses, and then deploy the contracts.
2. medusa is not great at decoding events that are emitted in internal libraries. See Bug: medusa fails to decode events emitted in internal library functions #131. The current fix is a brute-force approach to a better solution that would only parse the ABIs of libraries that the contract depends on.

Here are the technical requirements for the first feature:

• Figure out a way to identify whether a contract is a library or not based on the runtime bytecode.
• Identify which external libraries that a contract depends on based on the provided placeholders. This is an annoying and weirdly difficult problem. crytic-compile's solc and standard export has the necessary information to resolve this. However, it might be better to come up with an in-house solution for it so that we can re-use it for other compilation platforms (e.g., first-party support for foundry / hardhat).
• Update the test chain deployment process to first deploy the external libraries, update the contract bytecodes with resolved deployed library addresses, and then finally deploy the contracts.

For whoever picks this issue up, please reach out to me since I have done a lot of the legwork in the dev/library-support branch (requirements 1 and 3 are basically sort of done but not in the most elegant way). The hardest part is the second technical requirement which has an effective yet not-so-elegant solution that we can discuss.

Here are the technical requirements for the second feature:

• Identify which libraries a contract depends on. Note that this is different from a similar requirement in the first feature since internal libraries will not have placeholders but are rather inlined. I am not sure the best way to do this but ideally finding library dependencies is a single solution that can handle it for both feature 1 and 2.
• Update the execution tracer to navigate the library dependencies if an event does not match the ABI for the calling contract.