If you ask this question, you should not start designing toolkits ;-)
Putting jokes away, my view is the following (home made, no big names referred).
You have to build a software, which will solve a certain task. You have some specifications about different data objects, associated business logic, workflow, appearance, performance, etc. Requirements that your application have to meet in a certain environment (desktop or server, OS, frameworks, ...)
However, to achieve this goal, you probably will spend more time on "housekeeping" than implementing the actual algorithm, workflow, etc: you will store and read persistent data, process configuration information, command line parameters, scripts, manage the communication between the GUI and the business logic, handle errors. In more complex scenarios (like game development), you spend huge amount of time not on coding, but just building configurations (like design a level map, actors, etc), enable scripting and write scripts, ... Sometimes it is beneficial to create independent helper apps for doing such things. This latter stuff is what I would call "toolkit layer": not directly specified as a request, but you need them to do your job. And the better you design the toolkit layer, the more efforts it requires, but finally, when you have to solve your task, the tools make that pretty straightforward.
To put it simple: you can solve your tasks one by one independently - or extract the similarities, solve them once, and solving a "real" task means using the common layer in the specific environment. The problem: the common layer is
- inherently more complex, as it should answer "any" question instead of "one",
- hard to modify because many other codes depend on them,
- and when it breaks, it may crash just about anything.
Nice theory, tough stuff.
If you don't have a vision of the toolkit behind your current task, I think you should not design it. Design your application in a nice, object oriented way instead: interfaces, abstract classes, shared helper components. The latter will be your "toolkit layer" for this application. If you have designed it well, this layer will help you when adding "one last new feature" or component to the app just before the deadline. If you can estimate the required time well in this situation, your toolkit is good.
... and if you live on this toolkit-drug for 20 years, you will not see the application, only the toolkit layer. This is why I create an automatic JSON serializer with a common persistence layer, and a data binding GUI toolkit for my ever first iOS application. I simply can't do in another way (and Objective C / Cocoa rocks)...