Update to Windows Autopilot pre-provisioning process for app installs

This is all clear as mud. Can someone from Microsofts Intune development team (who's first language is English) please re-write the description of this functionality so that everyone doesn't have resort to reading user comments to try and comprehend what a "blocking app" does.

NOTE: If just had SCREEN SHOTS that showed us what a Blocking-App does (when it fails or succeeds) to every step that is has an effect on - we would all instantly understand what you are talking about.

Here is an rubric a for how you could write a numbered explanation as to what a blocking-apps success/failure to install actually does, and at what points that sucess/failure is relevant (and where it ceases to be relevant):

RUBRIC HOW YOUR ARTICLE COULD TELL US WHAT IT DOES (hypothetical example below it):

(A) What the BLOCKING APP does to the FIRST STEP AFFECTED by the BLOCKING APP in the provisioning process when it installs, and what it does when it fails (hence-forth the first relevant step will be called the RELEVANT STEP):

(A-1) What precisely happens to the provisioning process when a BLOCKING APP's installation FAILS at the RELEVANT STEP? I.E. Does it block others apps installations at the RELEVANT STEP, but only that step? If not what happens at FUTURE STEPS of provisioning?

(A-2) What happens to the provisioning process when a BLOCKING APP's installation SUCCEEDS at the RELEVANT STEP?
i.e. does this change FUTURE STEPS in provisioning in any way?

NOTE: If the BLOCKING APP is now done effecting any other provisioning steps SAY SO clearly that it now has no effect on any future step

(B-1)  If the BLOCKING APP FAILED at the first RELEVANT STEP of provisioning...  IS the NEXT STEP of provisioning effected, is so, why/how (e.g. Does the app try to install again at another step, and explain the conditions for that)?

(B-2) If the BLOCKING APP SUCCEEDED at the first RELEVANT STEP of provisioning.. IS the NEXT STEP of provisioning effected, if so and why/how?

(C-1) REPEAT (B-1) until you get to the point where the blocking app's failure has no effect on anything
(C-2) REPEAT explaining like in (B-2) until you get to the point where the blocking app's success has no effect on anything

IMAGINARY EXAMPLE:
Let imagine it works this way: Blocking Apps apply to the ESP page after the user's SSO is entered (and this is just hypothetical, as no one understands what you are saying in the description).... THIS is how you could CLEARLY EXPLAIN this as a process (if it worked this way):

1. You set app "SomeApp" as a Blocking App

2. if SomeApp fails to install during the ESP page (after user's SSO), it will BLOCK the rest of the apps from installing in ESP by failing/stopping the ESP process (if it's install succeeds, nothing changes and provisioning continues in the normal fashion)
3. If you have to option enabled to "Continue Anyway".  SomeApp will try to install again for a "SOME-NUMBER" of days/attempts after user login.If it installs, intune provisioning continues normally.

4. If SomeApp fails after "SOME-NUMBER" of attempts, SomeApp is done trying to install and no longer affects anything - it jsut won't continue to intall.

Again that is completely made up, but completely comprehensible - unlike what is written in this article.

Here is an rubric a for how you could write a numbered explanation as to what a blocking-apps success/failure to install actually does, and at what points that sucess/failure is relevant (and where it ceases to be relevant):

RUBRIC HOW YOUR ARTICLE COULD TELL US WHAT IT DOES (hypothetical example below it):

(A-1) What the BLOCKING APP does to the FIRST STEP AFFECTED by the BLOCKING APP in the provisioning process when it installs, and what it does when it fails (hence-forth the first relevant step will be called the RELEVANT STEP):

(A-2) What precisely happens to the provisioning process when a BLOCKING APP's installation FAILS at the RELEVANT STEP? I.E. Does it block others apps installations at the RELEVANT STEP, but only that step? If not what happens at FUTURE STEPS of provisioning?

(A-2) What happens to the provisioning process when a BLOCKING APP's installation SUCCEEDS at the RELEVANT STEP?
i.e. does this change FUTURE STEPS in provisioning in any way?

NOTE: If the BLOCKING APP is now done effecting any other provisioning steps SAY SO clearly that it now has no effect on any future step

(B-1)  If the BLOCKING APP FAILED at the first RELEVANT STEP of provisioning...  IS the NEXT STEP of provisioning effected, is so, why/how (e.g. Does the app try to install again at another step, and explain the conditions for that)?

(B-2) If the BLOCKING APP SUCCEEDED at the first RELEVANT STEP of provisioning.. IS the NEXT STEP of provisioning effected, if so and why/how?

(C-1) REPEAT (B-1) until you get to the point where the blocking app's failure has no effect on anything
(C-2) REPEAT explaining like in (B-2) until you get to the point where the blocking app's success has no effect on anything

IMAGINARY EXAMPLE:
Let imagine it works this way: Blocking Apps apply to the ESP page after the user's SSO is entered (and this is just hypothetical, as no one understands what you are saying in the description).... THIS is how you could CLEARLY EXPLAIN this as a process (if it worked this way):

1. You set app "SomeApp" as a Blocking App

2. if SomeApp fails to install during the ESP page (after user's SSO), it will BLOCK the rest of the apps from installing in ESP by failing/stopping the ESP process (if it's install succeeds, nothing changes and provisioning continues in the normal fashion)
3. If you have to option enabled to "Continue Anyway".  SomeApp will try to install again for "SOME-NUMBER" of days/attempts after the user's login to Windows. If it installs, intune provisioning continues normally and this no longer effects anything.

4. If SomeApp fails after "SOME-NUMBER" of attempts, SomeApp is done trying to install and no longer affects anything - it just won't continue to try and install SomeApp.

Again that is completely made up, but completely comprehensible - unlike what is written in this article.