Featuring three scripts:

1. abstractPartitions
   Given a ceil limit, say 4, and an input vector, say [ABC], would generate all the possible combinations without limiting itself to produce only those where each instance of the input vector would appear just once (for such a thing you may refer to my fullCollection() script) but producing even all the combinations where each given input letter would appear as many times as the limit (in our example 4 times) sets.
   It will proceed by subsets taking in one single letter, and would produce all the subsets (subsets of 2 instances, subsets of 3 instances, finally subsets of 4 instances) until the ceil limit is attained.
2. rangeAbstractPartitions
   Given a ceil limit, say 4, and an input vector, say [ABC], would generate all the possible combinations without limiting itself to produce only those where each instance of the input vector would appear just once (for such a thing you may refer to my fullCollection() script) but producing even all the combinations where each given input letter would appear as many times as the limit (in our example 4 times) sets.
   Will produce only those subsets whose length matches the given ceil limit (therefore in our limit example of 4, only subsets whose length is 4).
3. DNA
   This is the script which will first run the rangeAbstractPartitions script, and then for each produced entry would yield even all the anagrams.

Test them in the active forms to understand at a glimpse what they do.

For the DNA script (but not for the Partition scripts) we are taking avail of a few previously defined scripts, therefore they have to be included in your script to make the former work; for the codes along with all the explanations on their workings you can peruse the documentation in their respective files, for I won't repat here all that has been already documented there!

---

All this bountiful (©) stuff for free Please keep this website commented string as my only "reward"
allAnagrams()	hasher()
highestLast() & highestFirst()	dealEntries()

---

Now your codes, and after each code the active form and a few explanations.

---

ABSTRACT PARTITIONS

The code and the form and the explanations for this script

---

Arranging this script has been incredibly tough: you may regard this statement unusual only as long as, borrowing the script from someone's else sweat and efforts, you never took the chance to deal with this problem by yourself: so believe me, it required two weeks to find out the right conception.
The workings of the still variable are similar to the workings of the still variable used in the linearCollection() script which can be found clicking here, so read there to understand how the still variable works in the loop.
Under each letter (column) is gradually stored a set of combinations (rows) that all have in common a derivation form the leading column letter (A or B or C...): each row therefore starts with the leading letter (still variable, so array[still]).
One big difficulty is to slice off the newly generated subset in order to prevent the next loop from starting assembling combinations engaging the already used combinations: the storeStillLength variable takes care of that: for each column it keeps track of the level from where the latest generated combinations start being disposed, and this is critical because each row has a different such level: so we have a rows array which will store all the latest generated entries starting indexes, for each column: when we loop, we loop starting from such rows numbers, see:

---

for(var R=rows[C]; R<fixedLength; R++){

---

Also fixedLength is necessary since we will update the output length in the process, and therefore we need a variable that stores the output length before we start updating it;if we would have set as a limit something like the output.length itself, the loop would have never come to a close.

The script above is a bit different from the abstract partitions without range: it performs all by changing gradually the input by building up a starting row such as [AAAAAA] whose length matches the given range; then it goes on shifting (removing from head) and pushing (adding to tail) and saving the generated set (in order to reintroduce it in the loop soon after, for being shifted and pushed again), until it has crossed a full range of transformations.
The startIndex array is meant to keep a symmetrical record of each newly generated entry: in fact each generated entry must be able to spot its equivalent-level entry in the startIndex array.
In fact an entry such as, say, AAC should not start pushing in with A but with C: for if it would push in A, it would generate ACA: but such a combination A+A+C, as you can see clearly (AAC --< ACA!), was already there! So the subsequent elaboration of this subset (AAC) must start with C: and generate therefore not ACA but ACC . Hence, the startIndex array takes care to store for each newly generated subset the level it must start pushing in upon engagement, when the subset's back to its turn to generate a brand new subsets of combinations.

This script is a mere consequence of the other ones, and the only thing it adds to them is the anagram script I have detailed clicking here: you have to read that documentation to understand hwo anagrams work.
The only thing I feel like stressing is that if you select in within the anagram settings of the form a limit value, the outcome would:

1. Always show those combinations which are composed of the same letters (such as BBB or CCCC): in fact such a string gets parsed and anagrammed by the DNA script, but since the anagram of an input whose elements are all identical is still an anagram identical to the input string, well therefore whenever setting a limit to the anagrams, at least one instance of those entries composed by identical chars will be present. Anagrams are not performed on the whole output, but on each single entry of the output!! Therefore at least one instance of each combinations would be present, and on each of them the anagram possible limit is applied: this means that at least one instance for each generated Partition will be in place.
2. Since the Partitions always produce an amount, whenever you set a limit to the anagrams, this limit won't be set to the whole outcome, but to each time the allAnagrams function included in the DNA script is called in: and since this happens on each entry generated by the Abstract Partitions, for:

   ---

   for(var i=0;i<midway.length;i++){
   var X=allAnagrams(midway[i])

   ---

   well the consequence is that the limit is set on each invocation: therefore you will certainly get an output whose amount is higher than the set limit for the very simple reason the limit is not set on the whole outcome but on each single entry.
   Obviously if you'd use a function that sets a limit by selecting a random output on the whole outcome after it has been used a limit on each single entry, that would produce the kind of limit you probably think of: a precisely matching limit.
3. Arguments: give an array as input, set a range like in the ranged Abstract Partitions, then if you pass partitionTYPE argument as zero (default) would use ranged Partitions, otherwise the progressive partitions. All the subsequent arguments are optionals for the anagram function (see its own file).