Ttyjfyk

A contract that is upgradable would benefit from being able to accept ANY type, and forward that type to the current app contract based on how that ANY type parses. For example, a request might be sent to a contract which defines the current app contract, and the logic would be controlled by that contract. This would allow an app to have the same contract and have that contract choose where the request is sent. Is there consideration for an ANY type or a way that contracts might be made upgradable and fulfill this requirement? If not, is there a workaround

Perhaps ANY type is too liberal, but making a contract take (pair string (pair ... (pair ... ...))) etc.. and having storage maintain an address to generalize the contract in preparation for additional methods does feel like a kludge. I will note that a version of this technique has been used in Unix, so perhaps not as bad as I make it sound.

If you must, you can use bytes and PACK/UNPACK: http://tezos.gitlab.io/mainnet/whitedoc/michelson.html#operations-on-bytes

For 'any storage', you can use pair (big_map bytes bytes) ..., with your own conventions for the keys (perhaps packed pair/list/etc expressions with some string tags).

When doing these things you abandon some benefits of the type system.

There is currently no support or convention for 'tagged' data. When using bytes as an 'any' type, the consumer (who will UNPACK) should somehow already know the expected Michelson type and its particular semantics: the bytes only encode a Micheline expression, with no type (and no annotations).

If you just want to dispatch to a specified set of methods, who ses types are known, what you are looking for is the « alternative » type or sum type, where the value is (Left (Right (... )), ie a path of Left and Right constructors to the final type of the method.

Otherwise, if you want a completely generic version, allowing addition of new methods and types in the future, you can use UNPACK to extract the argument from a generic Bytes type. This way, all the methods are Bytes method, and you can dispatch using another argument (a hash of the method prototype for example). Though it solves your problem, it means that there is no static control any more at the boundaries of your contract : your code might contain an error, that will only be detected when the UNPACK will fail, maybe making your contract completely useless.