Update: This proposal has been approved - the remaining work is summarized in this comment.

Ideally, we'd have a consistent experience across all background-/thread-job related features, meaning that all of the following should exhibit the same behavior with respect to the current location that the script block being passed sees (by default:

• (a) Start-Job
• (b) Start-ThreadJob
• (c) postpositional & to start a job (implicit Start-Job)
• (d) ForEach-Object -Parallel

The most sensible location to use is the caller's current location, which (c) already uses and (d) will, once #10672 is merged.

The proposal is to make (a) and (b) behave like (c) and (d) for overall consistency and use of a sensible default:

(b) (Start-ThreadJob) was meant to be modeled after Start-Job's example, but currently isn't: it uses the - virtually unpredictable from a user's perspective - process-wide working directory; given that, it shouldn't be too late to change it - see PaulHigin/PSThreadJob#46

(a) (Start-Job) regrettably has always defaulted to $HOME (the filesystem provider's home location).

The question now is:

Can we consider Start-Job's default-to-$HOME behavior a bug / something worth fixing as a Bucket 3: Unlikely Grey Area change?

I'm certainly personally in favor of that, but I haven't looked into how likely it is that existing Start-Job code relies on $HOME to be the default directory.

@iSazonov's take (from his comment at #10537 (comment)):

I suggest to consider Start-Job case as bug.
If my work folder is c:\work and I run a job which switched to $home that is c:\users\isazonov - the last place is the worst place where user would like to see a resulting file. We could guess that user would use relative path to Documents folder. But most likely when faced with this inconsistency, the user will use the exact path to the working directory (c:\work), especially since the job is perceived as some kind of background process.