Thank goodness I've been around this community for a few years, because without having worked Habitability Detector and Look and Say I would have been utterly lost.

In particular, I immediately zeroed in on the metals side of the task.  Over-projecting the template atom to create the appropriate "quicksilver complement," as was common in Look and Say, is simple enough. But here, we run into the problem that this method is destructive.  That didn't matter in Look and Say, because we only need to read each input atom once, and another one is immediately available.  But here, we only get one chance to read the input, and the machine needs to then "remember" that state forever.

My first instinct was to create some sort of register.  Ever since biggie crushed everyone by using a register in Explosive Logic Unit, the idea has proven powerful time and time again.  But I felt continually blocked by one basic concept: in this puzzle, we do not know in advance exactly what shape the register will have!  The machine needs to be able to durably store any number from 0 (lead) to 5 (gold) with just a single set of instructions.    

I finally found inspiration by considering a related problem that crops up occasionally in TI: counting to numbers that are neither multiples nor divisors of 6.  The most common method is to build a stick, but rebix showed us something better in their winning Brazing Cathode I solution.  By "blocking" some of the grippers of an ordinary hexarm and positioning it for suppression, you can count to any number at all between 0 and 6.

That idea was the first thing I put on the board, and you see it here in the top left hexarm.  With a one-time assist from the simple arm below it, it grabs just enough salt to "block" however many grippers are needed (minimum 1), then slides over and handles only quicksliver forever after.  It is the cleverest idea in this machine by far, and I am quite proud to have found it.

**********

However, this clever hexarm does have a cost: it imposes a hard lower limit of Period 19, and thus 19R on metals.  Given that 15R is a natural target for  fast & efficient metal promotion, I figured I needed to save ~100 points on other metrics to remain competitive. 

There is a silver lining, however!  P19 may be a touch slow, but it is extremely permissive of complicated timing.  I took advantage of that in the element-detector machinery on the right, which uses 4 long loops to read the template.  Gratitude to Habitability Detector and Aether Reactor for giving me some tips on how to run this effectively.

***********

The first version of this machine reused the element-detector mechanisms to output subsequent saltlikes, so both elements and metals were output at 19R.  But a few days into the week, I read the metric description more closely: score is based on AVERAGE metrics, not WORST CASE!  So while 19R is my hard limit for metals, saltlikes might go as fast as 2.1R.  That offers up to 150 points of savings!

But I didn't immediately reach for the fastest possibility.  My only idea for distinguishing between metal and element cases was "use a wand," and my machine as currently designed only had one wand naturally available.  Given the necessity of both duplicating and debonding from that wand, I felt like I was limited to pseudoperiod 4 and thus R4.75.

After some sweating and cursing, I finally found a modified layout capable of handling elements at the faster speed, and eagerly rushed to submit and see how my score would plummet.  To my consternation, the improvement was a only a modest 20 points.  Why?!?!?!...Oh.  Yes.  Cost and Instructions.  I may have been saving 120 points on Rate, but it was costing me 60i and 40g to get the job done.  Seeing that, I decided that the faster rate probably wouldn't be worth it.  In fact, I got even better results from pseudo R6, as it allowed arm reuse.

***********

A little bit of old-fashioned OM optimization later, and here we are:
-P19, enforced by the projection hexarm
-19R on metals and 6.3R on saltlikes, for a combined average of 13.9R
-As little G, A, and I as I can manage.

My first-draft solve came in 200 points higher than this, and my first decently-optimized version 100 points higher, so I suppose I've come a long way.  But I must admit to being disappointed that I couldn't crack the triple digits.  I have a feeling that the best machines will get down to 900 or even less, and while I am definitely no wizard at computation, I would have liked to be in the same ballpark.  

Oh well.  I am sure folks will show me plenty of new ideas to steal and cite in future notes, when all is said and done!