CM: The Next Generation of SCM Standards

A Product is a collection of deliverables which together meet a product specification.  A Product may be a hierarchy of Products, with sub-Products being reusable across multiple Products.  So here's my take:

My Vote: Product, Project and IDE Project

Product:  A collection of deliverables which meet a product specification.
Project:  A managed set of Activities culminating in a Release or other milestone.
IDE Project:  The term used by some IDEs for their product file collections.

Process Flow

Process Flow, Work Flow, State Flow.  I'm not really sure if there is confusion about these terms in the industry - it's hard to tell.  But just to be sure, here's my take on them.

State Flow.  (aka. State-Transition Flow).  State applies to an Item/Artifact.  As it moves through the process it assumes different states which indicate who may act on it and what actions are permitted.  For example, a Problem moves from it's original state through a triage process that puts it in one of several states.  Eventually the Problem gets fixed or answered and reaches a "closed" state.  Only the originator of the problem can agree that it is closed - i.e. the original problem has been addressed, and this would only be done once the problem reached some sort of "fixed and tested" or "answered" state.

Work Flow.  Work flow shows how some input flows through the system to cause some output.  For example, a Request may cause a "feature" Activity to be created which may cause a change to Requirements.  The Activity may lead to the creation of product Changes, and Test Cases which are to be run on the changed product.  The Test Results might then cause the Request to reach an "implemented" state and then a release might result in the Request being marked "completed" and ready for "closing" by the originator of the Request.  Work flow documents the interaction of Items/Artifacts according to the planned process.  It highlights traceability actions that must be performed (hopefully automatically in most cases).  It does not focus on the who - the state flow deals with that.

Process Flow.  This is a broader term that encapsulates both State Flow and Work Flow. It also involves other aspects such as consolidation of Work Flows into an overall Release Process.  For example, milestones are met by performing regular builds which collect all (or a designated subset) of Changes which have been readied by the development team for a specific Product Development Stream.

Configuration
Configuration, Alignment, Baseline.  I don't think there is a lot of confusion here.  But let's clarify some things. A Configuration is an aggregation of a set of item revisions.  If the items are Requirements, we get a Requirements Configuration.  If the items are source code files, we get a Source Code Configuration.  You might want to aggregate unlike items, but let's not go there right now.  A Configuration typically consists of a consistent set of items (i.e. item revisions).  

The process used to create this consistent Configuration is sometimes referred to as Configuration Alignment - aligning the right revisions into a Configuration.   For this reason, you might find the term Alignment used as a synonym for Configuration.

Some might also use the term Baseline as a synonym, but this is not valid.  A Baseline is a frozen (i.e. never to be chanegd) Configuration.  Configurations can change, and dynamic Configurations, expressed as a set of rules for what should be in the configuration, change as the data in the CMDB changes. Now there may be tools that only permit you to create a Configuration by creating a Baseline,