What applications to create on a new project

A very wise trainer drilled into my brain that an application [in this context] is just "a collection of objects".
The primary purpose of an application is to move objects from one environment to another.

In previous versions of Appian, that product's dependency checking on import wasn't as good as it is today.  You needed a DS application to prevent dependency errors when importing new applications.  Product improvements over the years include smarter imports that recognize new data stores / entities first, so as to prevent dependency errors.

All that is to say that, for starters, one application is acceptable.

Over time, as your application grows, you might like to create new application objects for different reasons.  For example, after a major release, you might want to create an <<APP>> R2 application to help you more easily keep track of the objects that were added or changed after the first release.  You can do this again for R3.  

Some teams like to make a new application every day to further facilitate ultra-fine-grained tracking of changes. 
There are pros and cons to this approach that I'm not going to get into now.

Do what works for you and your organization.  

A very wise trainer drilled into my brain that an application [in this context] is just "a collection of objects".
The primary purpose of an application is to move objects from one environment to another.

In previous versions of Appian, that product's dependency checking on import wasn't as good as it is today.  You needed a DS application to prevent dependency errors when importing new applications.  Product improvements over the years include smarter imports that recognize new data stores / entities first, so as to prevent dependency errors.

All that is to say that, for starters, one application is acceptable.

Over time, as your application grows, you might like to create new application objects for different reasons.  For example, after a major release, you might want to create an <<APP>> R2 application to help you more easily keep track of the objects that were added or changed after the first release.  You can do this again for R3.  

Some teams like to make a new application every day to further facilitate ultra-fine-grained tracking of changes. 
There are pros and cons to this approach that I'm not going to get into now.

Do what works for you and your organization.  

Certainly a solid approach might be to construct one singular functionality to it's logical conclusion, this is your first "app".  You next "app" could be more functionality added to the same code base; make it do more.  Many of the speakers at Appian World last spoke about their first functionality being the start of a suite of functionalities that all fall under the same umbrella, and as Mr. Shankin is keen to point out logically belong in the same container called an Application.

I think it's important that for first iteration purposes we try to limit scope while using the full set of tools.  You'll want to keep feature creep off the initial project until you get a win, if you can.  Then, after victory, you can indeed add features.  If you do so in a more structured way, you have something akin to a regular product release cycle and less like a neverending battle against changing requirements.

Thanks Robert Shankin and all for your answers. 

Your answers were useful and helped me to decide to start with one simple application