Pipeline design patterns

Hello,

I am trying to get a fundamental understanding on complex version management in pipelines.
No matter how many times I read http://www.pipelinepatterns.com/theory/shapes.html I never come close to understanding it.
I am stuck at the internal consistency section U-Shapes in Parallel / Workspace Local Assets.

Question 1)
http://www.pipelinepatterns.com/zsvg/shapes_parallel_no_tooling.svg
Here an example:
1 - Geo artist checks in 1st modeling revision
2 - Texture Artist checks out alembic representation of 1st revision and starts working
3 - Because of parallelism in pipelines the modeler continues to work and makes new commits
4 - textureing gets to the point of checking in their work. they still reference an older revision of the geometry for which they would be able to make a consistent commit
However: Polson describes a pipeline where you always build the entire asset, so texturing has the option to:
a) build the consistent asset by building the asset with checking out the currently present geo revision
b)

the Geo Artist checks out, modifies, and exports the Geo, but in addition, checks out (read-only) and exports the Tex. the Tex Artist does just the opposite.

Which I interpret as: before the texture artist is ready to commit, he again makes a geo check out used for building the most up to date asset, but this seems to be contradiction to what is said above as

One common way to achieve internal consistency is for each artist to fully export the Local Asset, just to make sure their latest revisions are in sync with each other.

The way I understand it,
a) would lead to consistent asset, but to what I’d compare to a lost update in databases, as they override the head asset revision with older geometry. Plus now the geo head revision of source control is out of sync with the asset control
b) has the advantage that source control and asset control remain in sync / the asset is always in the latest possible state likely to be inconsistent.

I know the relation between geo and text might be a bad example here as I image them to work more in a linear fashion than parallel, but I took it as the example because he did.

Question 2)
In U-Shapes in Parallel he mentions

Developing components in separate workspaces creates some workflow difficulties.
Versionitis. Our artists can easily check in incompatible components. The asset will be internally inconsistent. They will need to carefully synchronize their checkins, of both the source and run-time data.

In this example he shows a different pipeline approach where each component commits only their work instead of building the entire asset. How is this a inferior design with regards to syncronisation and inconsistenies? I dont see how the full asset build solve any of these issues.

I am pretty sure I am misunderstanding something, so any help is greatly appreciated. Thanks