Ha, I knew there’d be a simpler way of doing it and that I’d be doing it wrong. 
I don’t think there should be anything wrong with your formula (even though, currently, there is):
[Table 1].Type.Unique().FormulaMap(CurrentValue + ":"+ [Table 1].Filter(Type=CurrentValue).Count()).BulletedList()
Both uses of CurrentValue are references to the FormulaMap instance rather than the Filter instance (even though the second use is inside a filter). I’d say this was ok.
The problem comes in because CurrentValue does double-duty to reference filter instances as well so you get a clash, but is CurrentValue really required in filters at all? For example:
[Table 1].Type.Filter(CurrentValue="Fruit")
…is functionally the same as…
[Table 1].Filter(Type="Fruit").Type
…which has no need for CurrentValue. It also “feels better” because follows the relational algebra rule “Do your SELECTs before your PROJECTs before your JOINs” (and might therefore be faster to execute as a result). If you don’t need CurrentValue in filters then the current implementation is fine and your lovely neat (and obvious now that I think about it!) code is also fine. Of course you then have a problem with all the code out there that does use CurrentValue in filters - maybe you could make a FilterValue instead?
Either way, however you fix the issue, some people are going to end up with broken docs - but that’s what betas are for. 
/edit - P.S. I still consider myself a noob at this. I’ve only been using Coda for a few weeks so I still have a lot to learn. This is a really good community.