First-class functions/closures as resources

I was wandering, now that resources/ownership/borrowing/etc are properly part of the component model; In what way are closures not "just" single-method resources? Can they piggy back off of the semantics and restrictions defined for resources?

For example, given the imaginary interface (& syntax):

interface A {
	register-event-handler: func(handler: fn(event));
	map: func(items: list<string>, mapper: borrow<fn(string) -> string>) -> list<string>;
}

Assuming that the following resource types are (automatically?) defined somewhere

resource fn-event { // fn(event)
	call: func(a1: event);
}

resource fn-string-string { // fn(string) -> string
	call: func(a1: string) -> string;
}

how is the first example different than this:

interface A {
	register-event-handler: func(handler: fn-event);
		// Fn is passed as "owned" handle. Ie. it's the responsibility of the
		// implementation of `A` to properly drop the resource/closure.
		// On the flip side, `A` can call `handler` as much as it wants even
		// after `register-event-handler` has returned.

	map: func(items: list<string>, mapper: borrow<fn-string-string>) -> list<string>;
		// Fn is borrowed. Ie. `mapper` may only be called during the
		// invocation of `map`, and must be dropped before returning.
}

?

By (re/ab)using resource semantics, this would keep function "references" in the realm of acyclic dependencies a.k.a. "no global GC required", right?

The issue names no files, tests, or entry points. Start by reviewing the component model's existing resource, ownership, and borrowing semantics, then compare them with the proposed closure examples. Done would require a settled design decision on whether closures can use resource semantics and what restrictions apply.