If you ask me what the best PPC is, then I would say that the 970 (G5) also known as "Antares" was it.
The load store unit was strong.
All address modes did work reasonable well (which is unfortunately not the case with most later PowerPCs)
The integer unit of the G5 was clock by clock quite good.
The G4 was in integer sometimes sometimes a little better clock by clock. But the G5 reached much higher clockrate, was stronger in float and because of its faster memory interface was not so limited as the G4.
The G5 decoder had some surprises but its good Out-of-order execution could make up for this.

Its a pity that the G5 was discontinued so quickly.
The G5 design was neat and did had good potential.
If IBM would had iterated on the G5 and had brought out newer versions with more cache or less power consumption then those could have been all great PowerPCs.

Its a shame that the PowerPC is vanished from the desktop.
But of course its would have been difficult to build proper desktop machines anyway with PowerPC. After the G5, no PowerPC CPU was produced that would make commercial sense to build a Desktop out of it. All PowerPC CPU which came out after the G5 were weaker than the G5 in general code performance.

Freescale: P3041: QorIQ P3041 Quad Core
EXTERNAL LINK 
Freescale: P5020: QorIQ P5020 and P5010 Dual and Single 64-bit Core Processors
EXTERNAL LINK 
Have they improved at all ?

You are right, we forgot the QUICKIES.
The PowerQuick live in their own little world.
I've not enough practical experience with them so I can not give a fair quote about them.
 

The moral that I take from this is: Easy of coding, and support for existing code is very important.

But we can also learn form the good and bad of the existing 68K chips.
Would someone like write up a little summery about the different 68K chips and their abilities and there strength and weaknesses?

That's why CISCs had much better code density over the RISCs. ARM included (which I think is one of the best RISC, and which have denser code compared to other RISCs).

It works well with a bunch of instructions: 4 is a good compromise.

simple:

instruction 1
jump if not zero l1
instruction 1
instruction 2
instruction 3
.
.
.
instruction 10
jump l2
l1:
instruction 11
.
.
.
instruction 20
l2:

simple case where 10 instructions have to be executed on zero and other 10 on non zero.

how do you optimize this?

imagine

if nonzero, 20 instructions, bitmap 01010101010101010101
instruction 1
instruction 11
instruction 2
instruction 12
instruction 3
instruction 13
.
.
instruction 10
instruction 20

here - it's just enough to have decoder that can digest 2 instructions per cycle. Good if it would be able to take 3 simple ones per cycle.

CPU will have each cycle 2 instructions to choose from and select one according to needs.

ACTUALLY no bitmap is needed. All you need is to give how much instructions are IF and how much are ELSE.
the sequence could be just predefined simply to make the instructions evenly mixed.

you know that memory throughput isn't a problem but memory latency is.

this make one (or even zero) cycle "branch" costs with unredictable branches.

the problem will be doing calls within such if-else fragments, which could perform nested if-else.

i think it can be handled by if-else stack but it's not needed.
simply disallow such things. If someone needs to call procedure from that sequence he should make it last instruction in sequence.
this both remove the need of nesting and improve branch logic - instructions before call will fill the pipeline and decoder could easily "predict" unconditional call/branch.

The CPU can not decide which halve of instruction to take until the BITMAP instruction has reached the very end of the pipeline where the flags are valid.

This means the CPU needs to execute all instructions of both groups.
This means in your 10 instruction group example the CPU has to executes 21 instructions.

I real BCC could be predicted and if predicted right then it would only execute 12 instructions.
If predicted wrong the BCC would execute 1+pipelinelength+other-halve. So in the wrong case the BCC would execute about 16-17 instructions.

So in any way the the BCC is far more efficient than the BITMAP solution.

I dont know the implementation details,
but I strongly suspect storing an exrta predefined Bit along with instructions is insignificant compared to all the effort modern CPUs go to, e.g. trying to do superscalar dispatch from variable length instructions, or accumulating information for branch-prediction

it's incredibly simple. decoder should turn all instructions into conditional instructions within if-else block, with some of them the condition equal to what if specify, other reversed (else).

ALU must be able to handle multiple instruction at once but ONLY by checking conditions and executing one per cycle with conditions right.

The result is like ALWAYS properly predicted branches.

Maybe crap but at least with ARM Thumb-2 it allows to execute big part of code branchless with no branching penalty. Even with only 4 instructions allowed within if-else block.

I think you are missing the fact that ALL instructions will be executed. But not all result will be written back.
This means the ARM using the IfThen instruction to make 4 instructions conditional will in any case have to execute 5 instructions - taking the time for 5 instructions.

EOR D5,D5  ; Z = 1
IFZ %101  ; LSB SR=101XNZVC
ADD D1,D2  ; bit 5=1, don't execute. LSB SR=010XNZVC
SUB D3,D4  ; bit 5=0, execute.      LSB SR=001XNZVC
ADD D5,D2  ; bit 5=1, don't execute. LSB SR=000XNZVC
...        ; execute following

EOR D5,D5  ; Z = 1
IFNZ %110  ; LSB SR=001XNZVC -> the inverse of %110
ADD D1,D2  ; bit 5=1, don't execute. LSB SR=000XNZVC
SUB D3,D4  ; bit 5=0, execute.      LSB SR=000XNZVC
ADD D5,D2  ; bit 5=0, execute.      LSB SR=000XNZVC
...        ; execute following

Don't know if it would work. Don't think it's worth it. ;)