AFAICS this is not Spaces specific but also applies to e.g. setting an initial custom task policy when creating a task: Foobar changed the visibility from "Public (No Login Required)" to "Custom Policy".
So far I'm aware of two WM Phab users who contacted me, concerned that the tasks they created were public for a short moment and might have created public notifications.

On the other hand, there were observable effects in the similar case of T7284

This is definitely confusing and something we should fix. (We may get it from T9132 cheaply.)

The reason some fields show a "User Q changed field F from X to Y." when creating objects is that we set default values for those fields. For fields like "Title" and "Description" the default is empty, and for fields like "Subscribers" we phrase the edit as "User Q added subscribers..." which always makes sense, but for "Space" and "Policy" controls we choose defaults based on the viewer and application configuration.

Internally, the edit layer ("ApplicationTransactions") sees the object as having the default value to begin with, and sees a change from the default to the selected value. This is "accurate" in a vague technical sense (the user really did change the control) but confusing and inconsistent from a user perspective (and users don't generally care what another user's application-configured default value was). I think the right product behavior is:

• If the user kept the default, render nothing.
• If the user changed the default, render "User Q set field F to Y." (e.g., "User Q set the visibility to 'Custom Policy'.").
• For normal changes after creation, continue rendering "User Q changed field F from X to Y." (e.g., "A changed the visibility from 'Custom Policy' to 'Public'.").

Any implementation of this will benefit from T9132, even if that doesn't give it to us completely for free.

T7661 is also similar.

After D14811, here are the new behaviors:

If you create a task without changing the policy controls in the form, no transaction will render. No transactions mean everything is set to the defaults.

If you create a task but change the space or policy from the default, you'll get a special transaction which is more clear, and can't be misread as "created with a public setting, then really quickly made it private". All of the underlying behaviors have always reflected this new language, but the old language was definitely less clear in describing how things worked under the covers. The new language is something like this:

alice created this object in space S2 Secret.

If you see this transaction, it's now a hint that means the author changed the policy or space from the default when creating the task.

Normal edits are unaffected by this change, and still render as "changed the whatever from X to Y".

(This change respects form defaults, including defaults set by customizing "Create" forms -- see https://secure.phabricator.com/book/phabricator/article/forms/. If you use a "New Special Admin Task" form which creates objects into a particular space by default, transactions will only render if they change settings away from the form defaults, not the global defaults.)