Migrating to Salesforce DX - Artifacts?

I'm trying to manage my own org's migration to SalesforceDX, and I'll say that the terminology that Salesforce uses is a bit too vague for my tastes (and not entirely consistent).

An 'artifact' is just an abstract concept that seems to be used to refer to both individual components (Apex Classes, Workflow, Validation Rules, SObject fields, Visualforce pages, etc...) as well as a collection of components (say, a Visualforce page, along with its controller extension class, static resources, an SObject field that only it uses, and a permission set). The definition seems to change between different sources (say, the SFDX module and the SFDX webinar).

After wrestling with the inconsistent terminology, here's my understanding...

• Individual metadata/code (a field on an SObject, a List View, an Apex class, a Tab, a Page Layout, etc...) are Components
• One or more components create the abstract unit called an Artifact. Any single component can exist, at most, in only one Artifact. App Exchange apps are an example of an Artifact. My org contains code to generate Gantt Charts using d3.js. The d3.js source (as a static resource), a Visualforce Component, a pair of controllers (and test classes for them), and a pair of Visualforce pages that use my component (so I can include the chart in page layouts) comprise my Artifact.
• An Artifact should be (ideally) completely independent. If you deploy an Artifact to a scratch org, you should be able to run the unit tests included with that Artifact, and they should pass.
• A Project is something that exists on your local computer(s). It can contain multiple Artifacts. A Project is the intermediary between version control (source form), and Salesforce proper (metadata api form).

Unless you plan to offer your Artifact on the App Exchange (either as a managed, or an unmanaged package), then packages in Salesforce don't play that much of a role in SFDX at this time. Building an unmanaged package is just one way to get specific pieces of metadata/code from an org into an SFDX project. Once you have it in SFDX, the idea is that you'd push things into version control. At that point, the unmanaged package has served its use, and should be discarded. The unmanaged package won't help you deploy code between orgs.

Components that are used by multiple Artifacts don't really fit well in the current SFDX model. I'm not sure if SFDX absolutely can't deal with having one Component appear in multiple Artifacts, but it's not a good idea to do that even if we can (how would changes to the Component in one Artifact affect the same Component in another? How would we choose which version to use? Could choosing one over another even be done automatically in a reliable manner?).

For Components that would reside in multiple Artifacts (SObjects, Validation Rules, Fields, etc.. will be common targets for this distinction), we need to put them in a completely separate Artifact. At that point, we start having dependencies between Artifacts.

At this time, Salesforce does not have a good solution for managing dependencies. If you have one Artifact (artifact b) that depends on another (artifact a), you'll need to manually deploy Artifact A to your scratch org, sandbox, or production before you deploy Artifact B.

Salesforce is currently working on improving the way packages work (Packages 2.0), and the hope is that the new version of Salesforce packaging will address issues with dependencies between Artifacts. It's currently in beta, as of Winter '18 (API v41.0), and about the most information you'll find about it at this time is through the Packaging 2 Salesforce Success Community Chatter Group