I propose that instead of declaring a resource or subsignal a clock at the top level, it would be done as follows:

class TinyFPGABXPlatform(LatticeICE40Platform):
    device     = "iCE40LP8K"
    package    = "CM81"
    resources  = [
        Resource("clk16", 0, Pins("B2", dir="i"),
                 extras={"IO_STANDARD": "SB_LVCMOS33"},
                 frequency=16e6),
        # ...
    ]

Bikeshed: maybe this would be slightly more elegant?

class TinyFPGABXPlatform(LatticeICE40Platform):
    device     = "iCE40LP8K"
    package    = "CM81"
    resources  = [
        Resource("clk16", 0, Pins("B2", dir="i"), Clock(16e6),
                 Extras(IO_STANDARD="SB_LVCMOS33")),
        # ...
    ]

The implementation would be similar to the current one: the platform.request("clk16") call would discover the Clock element in the resource description, and automatically call platform.add_frequency_constraint. Of course, if a clock does not have a fixed frequency, it is always possible to omit the Clock element and add the constraint manually.

Just to add a data point: Some platforms, TinyFPGA A in particular, don't actually have a clock pin, instead relying on the FPGA's internal oscillator. I did some things I'm not exactly proud of to get it to play nice with omigen, even if the commit was accepted.

So if there is a way to more nicely support internal clock constraints or otherwise without a do_finalize dance or request overload, I'm open to feedback.

Right, so that's a related but different situation: defining frequency constraints on ports and on nets. Currently nextpnr is deficient in that it does not allow to reliably define a frequency constraint on a net, so we're going to have to teach platform.add_frequency_constraint to distinguish ports and nets, and only support for ports will be an absolute requirement for any new platform.