When creating a new pix_icon instance, you are only able to pass a pix path (e.g. i/calendar) to it. Later, when the pix_icon is rendered in a theme

• if the theme is using icon_system_standard, this pix is output directly as an img tag
• if the theme is using icon_system_fontawesome, this pix mapped to a FontAwesome icon and the pix is output as FontAwesome icon tag.

This approach is fine for backwards-compatibility, but it has three main downsides for developments which only target FontAwesome-capable themes like Boost and Boost Child themes:
1. When creating a new pix_icon instance, you always have to pass a pix path first and have the create an additional FontAwesome mapping which is a code overhead.
2. The pix file is expected to exist on disk, even if it is never rendered in the theme, which is also an overhead.
3. The pix file should cohere visually with the mapped FontAwesome icon which isn't always possible without creating new icon files (which will never be rendered as mentioned in 2.)

That's why I would like to propose to add native FontAwesome support to the pix_icon class to simplify the work with FontAwesome icons in themes like Boost.

This is especially relevant in code areas where I must use pix_icons (e.g. when adding an icon to a navigation_node instance) and cannot use a custom icon rendering mechanism.

TL,DR:
As a developer working on code for a FontAwesome-capable theme like Boost and Boost Child Themes, I want to be able to use FontAwesome identifiers like "fa-check" when creating a pix_icon instance without having to add any pix fallbacks which will never be rendered in my theme.