Resolves YES if markets can be (or must be) created in a "closed" or "draft" status. While "draft", they would act similarly (in my judgment) to "closed" markets which have passed the closed date. People can make comments, the creator can edit the question and description, etc, but regular bets cannot be placed.

Resolves NO if this feature does not exist by market close (2023-06-02).

Resolves NO if something like this can only be achieved via a workaround such as creating a market using the API with a close date in the past.

Features that don't impact resolution: Maybe the creator can place bets to adjust initial probabilities. For multi-response and free-response markets maybe the creator can create responses. Maybe bettors can place limit orders to be executed when the market opens. Maybe a market can have an "open date" when it is automatically opened. Maybe a draft market is displayed differently on the home page. Maybe markets can be opened and closed on a schedule.

Use cases:

1. I am running a tournament or other scheduled event, and I want all my markets to open when the event starts. For many reasons which I can describe in comments if asked. This was the trigger for this market.

2. I want to create a market but I'm not sure of the wording, criteria, etc. I can make a draft market and get feedback.

3. I want to create a market but I'm still working on it. I can create a draft unlisted market for now, and list it and open it when I'm ready.

4. I am making a free response market and I want to provide several initial answers with sensible probabilities before the market opens. For example, I want a "who will the candidate be?" market and I don't want someone else to bet for the two front-runners and scoop up free mana.

5. I am making a fixed response market but I want suggestions from bettors on what the fixed responses should be. For example, I want to make a "what suggestion will improve my life" market and I want to accept only suggestions I like from the initial comments.

Negatives are the usual ones: ui complexity, dev time, code complexity.