I'm building a marketplace that needs to handle multiple asset types with different ability requirements, and I've hit some fundamental questions about Move's type system. I want to store different asset types in the same collection, but they have different abilities:

• Regular NFTs: key + store (transferable)
• Soulbound tokens: key only (non-transferable)
• Custom assets with transfer restrictions

public struct Marketplace has key {
    id: UID,
    listings: Bag,  // Want to store different asset types here
}

// This works for transferable assets
public fun list_transferable<T: key + store>(
    marketplace: &mut Marketplace,
    asset: T,
    price: u64
) { /* ... */ }

// But how to handle soulbound assets?
public fun list_soulbound<T: key>(  // No store ability
    marketplace: &mut Marketplace,
    asset_ref: &T,  // Can only take reference
    price: u64
) { /* How do I store metadata about this? */ }

Key Questions:

• Ability Requirements: When using dynamic_field::add<K, V>(), does V always need store at compile time? Can wrapper types work around this?
• Heterogeneous Storage: Can a single Bag store objects with different ability sets (key + store + copy vs key + store), and handle them differently at runtime?
• Type Safety: Since dynamic fields perform type erasure, how do I maintain type safety when retrieving values? What's the pattern for storing type metadata?
• Witness Pattern: How do ability constraints work with phantom types? Can I store Asset<Type1> and Asset<Type2> in the same collection and extract type info later?

Building a system where NFTs, soulbound tokens, and restricted assets all need marketplace functionality but with different transfer semantics.

I’ve tried wrapper types, multiple collections per ability set, separate type metadata storage. Each has tradeoffs between type safety, gas costs, and complexity.