Taking the first question, in an ideal world, there is no real reason for components to be different from functions. But, consider what would happen in a large system with thousands of functions: all these thousand components would have to be tracked for changes, and configuration management would have to comprehend the links between changes in these thousands of components. This is a difficult job, but it becomes an order-of-magnitude more complex when we consider a "product-line" development environment where multiple variants of functions are being maintained simultaneously. This complexity can be reduced by bundling up multiple functions into components -- we have to track smaller number of components for configuration management.
So what metric should we use to design components? Which functions should be bundled together? Since our metric is to minimize the number of versions that we need to track, we need to put functions that "change together" into a component. From a product-line perspective, we need bundle together functions that "appear together" within products of the product-line. Both these metrics can be easily identified by looking at the version-control history and the product-line bill-of-components respectively. These are not the only two dimensions, there may be other criteria -- for example bundle together functions that need access to similar computing resources (floating-point arithmetic for instance).
