[..]

    Or I think the better approach might be to make your own subclass of the hold browser
    that /doesn't/ react to Ctrl+End, which should be easy to do, and will guarantee it doesn't
    steal the events you want.

    In your subclass handle() method, you can check for Ctrl+End and ignore the event
    by just doing a return(0); when it's received. This will eclipse the event from the base class
    so it can't react to it. Pretty sure this would work: [..]

    Here's a small working example program that demonstrates that technique.

    Here I created two widgets:

•     "MyHoldBrowser" which subclasses Fl_Hold_Browser and has the handle() method
      I mentioned that forces it to ignore the Ctrl+End key combo. ("End" will still work
      for moving the scrollbar, just not with the Ctrl key included in any way)
  
  
•     "MyEndWidget" which simulates your widget that 'needs ctrl-end as a shortcut',
      and prints a message to the console when it's able to see that key combo as a shortcut,
      showing the event is not stolen by the hold browser.

    When you run the app, hitting Ctrl+End should print the message indicating MyEndWidget
    was able to process the event.

    As an experiment, you can try commenting out the entire MyHoldBrowser::handle() method
    (shown in blue below), then it will act like the default Fl_Hold_Browser, and you'll see Ctrl+End no longer
    prints the message, replicating the "event stealing" behavior you mentioned. This would show the
    subclassing technique with the handle() method solves the issue.

#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Hold_Browser.H>
#include <FL/Fl_Box.H>

class MyHoldBrowser : public Fl_Hold_Browser {
public:
  MyHoldBrowser(int X,int Y,int W,int H,const char *title=0) : Fl_Hold_Browser(X,Y,W,H,title) {
  }
  int handle(int e) {
      // Specifically ignore the Fl_End + FL_Ctrl key combo 
      // so other widgets may use it
      switch (e) {
          case FL_KEYDOWN:     // keyboard press events (aka. FL_KEYBOARD)
          case FL_KEYUP:       // keyboard releae events
          case FL_SHORTCUT:    // keyboard shortcuts
              switch ( Fl::event_key() ) {
                  case FL_End:                              // Fl_End pressed?
                      if ( Fl::event_state() & FL_CTRL )    // Ctrl key also pressed?
                          { return 0; }                     // eclipse event from base class so other widgets can use it
                      break;
              }
              break;
      }
      return Fl_Hold_Browser::handle(e);                    // all other events pass to base class
  }
};

class MyEndWidget : public Fl_Box {
public:
  MyEndWidget(int X,int Y,int W,int H,const char *title=0) : Fl_Box(X,Y,W,H,title) {
  }
  int handle(int e) {
      if ( e == FL_SHORTCUT &&
           Fl::event_key() == FL_End &&
           Fl::event_state() & FL_CTRL ) {
          printf("Handling Ctrl-End!\n");                  // debugging
          return 1;
      }
      return Fl_Box::handle(e);
  }
};

int main()
{
    // Make window with the border color
    Fl_Double_Window *win = new Fl_Double_Window(800,800,"Test");

    // Create our own Hold Browser subclass
    MyHoldBrowser *brow = new MyHoldBrowser(10,10,300,800-20,"Hold Browser");
    {
        // Make 100 items in the browser so scrollbar appears
        char s[80];
        for (int t=0; t<100; t++ ) { sprintf(s, "%04d", t); brow->add(s); }
    }

    // Create our own widget that needs Ctrl+End
    //     If it receives that key combo, it prints a message to the screen.
    //     Let's create this /last/, ensuring that widget creation order 
    //     doesn't matter to make this technique work.
    //
    MyEndWidget *myend = new MyEndWidget(400,10,300,800-20,"My Widget");
    myend->color(FL_RED);
    myend->box(FL_FLAT_BOX);

    win->end();
    win->show();
    return Fl::run();
}

Although I didn't try it, I think what would also 'work' is if you left the default Fl_Hold_Browser
behavior intact, and just created the MyEndWidget first, and the hold browser after that.
Changing the order should (I think) also allow your widget to get the shortcut event first,
without having to subclass Fl_Hold_Browser.

But depending on widget order might be hard to maintain, and be too obscure, so I think
the above behavior might be the better choice.